bugGNU Octave - Bugs: bug #63129, Install on Windows 10 breaks...

 
 

bug #63129: Install on Windows 10 breaks permissions of temp folder

Submitter:  None
Submitted:  Thu 29 Sep 2022 08:37:56 AM UTC
 
Category:  Other Severity:  4 - Important
Priority:  5 - Normal Item Group:  Installation Failure
Status:  Fixed Assigned to:  None
Originator Name:  ehz Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 7.2.0
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Sat 08 Oct 2022 11:34:43 AM UTC, comment #20: 

I grafted that change to the release branch of MXE Octave here:
https://hg.octave.org/mxe-octave/rev/78b9fc115590

Closing as fixed.

Markus Mützel <mmuetzel>
Project Member
Tue 04 Oct 2022 05:52:37 PM UTC, comment #19: 

~nightly builds are located at

https://buildbot.octave.space/#/download

I tested with octave-2022-10-03-00-12-default-w64-installer.exe.  

Nicholas Jankowski <nrjank>
Project Member
Tue 04 Oct 2022 04:49:19 PM UTC, comment #18: 

Could you point me to where the new version of the installer is once it's been uploaded to a server? I think bug #63148 is a duplicate of this same problem, except on Windows 7 instead of 10. I can at least point that user to the newer install if they don't respond.

Arun Giridhar <arungiridhar>
Project Member
Tue 04 Oct 2022 02:55:53 PM UTC, comment #17: 

If I thought there was a confirmed exploit I probably would have raised severity to 6-Security.  I raised it to 4-important because it's creating a persistent, corrupt permissions state affecting part of the operating system outside of octave itself for (it seems) everyone who has used the 7.2.0 executable installer. it created system configuration errors for me on viewing permissions settings in Temp, and there's another report that might be related indicating more significant system impact. (bug #63148). With Windows being Windows I would not doubt that any impact all be highly variable with particular setup and security model.   I was not insisting the installer be pulled, but felt the question was worth raising.

I looked back at another system that I believed used the v6 installers, and didn't see the issue, but I haven't started stepping back through each to verify when it might have started.

Nicholas Jankowski <nrjank>
Project Member
Tue 04 Oct 2022 07:15:14 AM UTC, comment #16: 

I'm not sure if this requires us pulling any installer. (Imho, it doesn't.) I still don't understand why this is an "important severity" bug. What is the exploit vector that would justify that classification?
Is this even a regression in 7.2.0? What was the first version that shows that behavior? That mount was added some time during the development cycle of Octave 5 (early 2020, almost 3 years ago) afaict.

Markus Mützel <mmuetzel>
Project Member
Mon 03 Oct 2022 06:51:38 PM UTC, comment #15: 

I'm not sure the comment #14 issue is related to this bug report. That's a windows 'feature' that has been around for quite some time.

updating the status of things, I downloaded todays build Mon, Oct 03, 2022 (hg id: 24247d13a44b), verified temp folder had clean permissions, and ran the exe installer. following installation, no change to Temp folder permissions.

I think we can call this fixed on stable, so it'll catch the 7.3 release. 

Is it significant enough that we should pull the exe 7.2.0 installer from the main download site?

Nicholas Jankowski <nrjank>
Project Member
Fri 30 Sep 2022 05:32:35 PM UTC, comment #14: 

[OT]
FWIW, there may be another issue with Windows Temp folders and downloaded files:
I found that automatic updates for e.g., Thunderbird and notepad++ and many other SW don't work since quite some time. After I got sufficiently fed up with this I did some searching and I read somewhere that files (notably executables) downloaded from the Internet are silently tagged as such by Windows and cannot be executed from the Temp folder (and ISTR that it may even apply to downloaded files in any folder).
The fix I found turned out to simply to copy (and not move or symlink to) the installer file to somewhere else, e.g. the desktop, that copying action suffices to remove the tag for the copy.
This tagging may depend on the Windows version (at home I have Professional and at work Enterprise).

Philip Nienhuis <philipnienhuis>
Project Member
Thu 29 Sep 2022 05:26:38 PM UTC, comment #13: 

playing around with the latest stable build (29 sep 2022, Octave 7.2.1    (hg id: 96ad887ae4f8), so not with this last change)  just confirming what everyone else said below.  I didn't notice permission changes anywhere else.

will verify after the next buildbot cycle picks up markus's change that it's fixed on my system.

for everyone caring to do cleanup, the following commands run from a command prompt with Administrative privileges** will reset the permissions to default:

cd %USERPROFILE%\Appdata\Local
ICACLS Temp /reset /T /C

from https://answers.microsoft.com/en-us/windows/forum/all/how-do-i-restore-temp-folder-permissions/92f7fa62-7efa-4afc-8885-9bea20aa840f

after which the Temp folder and all files/subfolders should revert to the windows default permissions.

(shouldn't be needed here, but if the above command doesn't work, you may need to first 'take ownership' of the files by running

TAKEOWN /F Temp /R /D Y

is something we should advertise more broadly?

    • Click on the Start button, type CMD, select Run as Administrator
Nicholas Jankowski <nrjank>
Project Member
Thu 29 Sep 2022 01:59:29 PM UTC, comment #12: 

I don't know which unexpected side-effects adding `noacl` could have. The test suite still passes with that change. So, I pushed it to MXE Octave here:
https://hg.octave.org/mxe-octave/rev/a28c2b488272

Marking as ready for test.

Markus Mützel <mmuetzel>
Project Member
Thu 29 Sep 2022 01:08:31 PM UTC, comment #11: 

@markus see comment 9

Without that mount point, anything using /tmp will use the /tmp of the install rather than the windows temp - not sure if would effect msys commands only ?

There was a bug report where files were getting created in /tmp, and some in windows temp but I cant remember the bug number

Its easy enough to change it to add the noacl

John Donoghue <lostbard>
Project Member
Thu 29 Sep 2022 12:00:06 PM UTC, comment #10: 

Running the "Bash shell" shortcut with elevated privileges causes the permissions on the temp folder to change.
Running it without elevated privileges leaves the permissions untouched.

When I add `noacl` to the properties of that mount point like you suggested, the permissions stay intact no matter whether I run the bash with or without elevated privileges.

Do you know why we have that mount point? Which operations might be affected by that change?

Markus Mützel <mmuetzel>
Project Member
Thu 29 Sep 2022 11:53:43 AM UTC, comment #9: 

If i recall correctly with the fun of TMP, TEMP, TMPDIR and whatever there maybe as well as msys /tmp, that line mounts /tmp to the windows temp dir.

If we can see the change running when running bash, it should be easy to try the mount point change to see if that works

John Donoghue <lostbard>
Project Member
Thu 29 Sep 2022 11:44:28 AM UTC, comment #8: 

i bumped severity mainly because it's unexpectedly changing security settings on the system in a persistent way, with the potential to affect things outside of octave itself. system temp folders are often malware vectors, which is part of the reason we've seen windows systems with extra username/appdata/local/temp folder security restrictions causing difficulty with things like pkg installs. even if the change is innocuous, it's the kind of thing that gets certain software flagged as not-permitted-for-installation in certain environments.

Nicholas Jankowski <nrjank>
Project Member
Thu 29 Sep 2022 11:41:24 AM UTC, comment #7: 

Crossed with your latest comment.
I didn't know we do this. But that might be it. 👍

Markus Mützel <mmuetzel>
Project Member
Thu 29 Sep 2022 11:38:24 AM UTC, comment #6: 

Maybe, we should set TEMP (and TMP?) to `%ROOT_DIR%/tmp` when running the script with elevated privileges from the installer?

Markus Mützel <mmuetzel>
Project Member
Thu 29 Sep 2022 11:37:30 AM UTC, comment #5: 

the .bat file does call msys to initialize it - my guess is soemthing with the temp dir mounting

in the installed files /etc/fstab

   none /tmp usertemp binary,posix=0 0 0

Mounts the windows temp dir to /tmp - perhaps it should be

   none /tmp usertemp binary,noacl,posix=0 0 0

John Donoghue <lostbard>
Project Member
Thu 29 Sep 2022 11:35:22 AM UTC, comment #4: 

Maybe the issue is that the post-install script is running with elevated privileges (like the installer)?

I'm not sure about the severity.
I'm seeing the same warning and permissions for a NULL SID user (and the others). (I don't know since when that is that way.) But I didn't notice any adverse side effects...

Markus Mützel <mmuetzel>
Project Member
Thu 29 Sep 2022 11:30:22 AM UTC, comment #3: 

I usually use the zip packages on windows, but in the one machine where I have used the installer, I'm noticing something similar in my temp location (%Appdata%/Local/Temp).  I'm using Windows 10
 21H2, build 19044.2006. when I navigate to that temp folder, select folder Properties, and the Security Tab, I get a warning message:

"The permissions on Temp are incorrectly ordered, which may cause some entries to be ineffective."

It offers to let me Reorder the list or Cancel to continue in view only mode.

There in the Group or user name list I see:

NULL SID
Everyone
CREATOR OWNER
CREATOR GROUP
SYSTEM
Admin
Administrators

Selecting the Advanced view button at the bottom, I see something similar to what you describe. (my ss attached.)  I have not stepped through uninstall, cleanup and reinstall yet, but based on the permissions I'm seeing I think we can at least tentatively confirm your report.  Also escalating the severity of the report.


Nicholas Jankowski <nrjank>
Project Member
Thu 29 Sep 2022 11:18:05 AM UTC, comment #2: 

The installer shouldnt be changing any permissions. My guess would be msys2 environment underneath it may? be the culprit?

Can you change the permissions back to what they should be, leave octave installed and then run the Bash shell from the windows program menu within the octave links and see if that causes the change.

John Donoghue <lostbard>
Project Member
Thu 29 Sep 2022 11:17:31 AM UTC, comment #1: 

That might be some MSYS2 action (in the post-install.bat script?).

@lostbard: Any idea what might be going on?

Markus Mützel <mmuetzel>
Project Member
Thu 29 Sep 2022 08:37:56 AM UTC, original submission:  

I think this the same as the closed "bug #60912: Installing with installer corrupts permissions on temporary directory (temp / tmp)".  I am submitting as new because I don't know the right protocol when trying to reopen a bug with a different version of Octave than the original bug.

The issue is that my temp folder permissions are changed to something unusable by the Octave 7.2.0 installer.  It goes from what you see in file clean-permissions.png to corrupted-permissions.png.

Of note: I use a non-default temp folder, with %TEMP% and %TMP% set to "C:\Temp".  Octave does see the correct value of these environment variables when it runs, verified with getenv("TEMP") and getenv("TMP").

I am running Microsoft Windows 10 Pro, version 10.0.19044 Build 19044.

By the way, I am certain it is the Octave the installer changing the temp folder permissions.  After cleaning up the permissions manually, I immediately reinstalled Octave and the permissions were yet again askew.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53771:  Permissions_screenshot_confirm.png added by nrjank (44KiB - image/png - image of similar strange permissions after install on a different machine)
file #53766:  clean-permissions.png added by None (28KiB - image/png - Images of temp folder permissions before and after Octave install)
file #53767:  corrupted-permissions.png added by None (50KiB - image/png - Images of temp folder permissions before and after Octave install)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by nrjank (Updated the item)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by mmuetzel
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-08 mmuetzel Open/ClosedOpen Closed
    2022-10-08 mmuetzel StatusReady For Test Fixed
    2022-09-29 mmuetzel CategoryNone Other
        StatusConfirmed Ready For Test
    2022-09-29 nrjank Attached File- Added Permissions_screenshot_confirm.png, #53771
        Severity3 - Normal 4 - Important
        StatusNone Confirmed
    2022-09-29 mmuetzel Carbon-Copy- Added lostbard
    2022-09-29 None Attached File- Added clean-permissions.png, #53766
        Attached File- Added corrupted-permissions.png, #53767

    Back to the top


    Powered by Savane 3.9