bugGNU Octave - Bugs: bug #60912, Installing with installer corrupts...

 
 

bug #60912: Installing with installer corrupts permissions on temporary directory (temp / tmp)

Submitter:  Arthur Tacca <arthur_tacca>
Submitted:  Mon 12 Jul 2021 10:44:13 AM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Need Info Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 6.2.0 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 14 Oct 2021 09:41:15 PM UTC, comment #12: 

Checked at home: No problems when installing from a restricted rights user account (used a copy of the installer I downloaded at work). Difference with work is that my home computer system TMP and TEMP environment variables point to %SystemRoot%\TEMP, and my user account TMP and TEMP env variables point to %USERPROFILE%\AppData\Local\Temp.
At work, all point to C:\temp.

At work, the sysadmin repaired the access rights to temp, I'm very hesitant to start experimenting with installing via the zip file, as I can't repair anything myself. As indicated, I installed 3 times on three different (work) computers (with the same base image). The time I installed from the zip file, I did not have complications. The two times I installed from exe, access rights were corrupted. Although I think it was the octave installer that caused this, I cannot be sure, as both times I installed Python and Fusion 360 as well.
I'll check at work what getenv("TEMP") and getenv("TMP") return, but I expect it will be C:\temp (as this is what the environment variables for system as well as user are set to).

Thanks for the help and suggestions.

Peter Kruijt <p8r>
Thu 14 Oct 2021 06:40:25 PM UTC, comment #11: 

@p8r:
What do these Octave commands:

getenv ("TEMP")
getenv ("TMP")

return?
In my case using the Windows default TEMP and TMP settings for limited user accounts of "%APPDATA%\Local\Temp" work better than "C:\Temp".
For me, the Octave commands above returned "C:\Temp\2" rather than "C:\Temp" -- go figure. After setting it back to the Windows default (see comment #5) Octave worked correctly again here.

What happens if you unzip the .zip "installer" rather than run the executable installer, does that work better?  (after unzipping, don't forget to first run 'octave-firsttime.vbs' in a CMD shell, and copy 'octave.vbs' as a shortcut to your desktop.)

Philip Nienhuis <philipnienhuis>
Group Member
Thu 14 Oct 2021 11:50:01 AM UTC, comment #10: 

I will check at home if the same happens when installing from a limited rights user account. Don't know if there's a difference in behaviour between user accounts and accounts with admin rights. It's the second time out of three that this happens after an installation of octave (assumed). Two times I used the exe, the other time I installed from a zip file. All were Octave 6.3.0.

Peter Kruijt <p8r>
Thu 14 Oct 2021 11:23:21 AM UTC, comment #9: 

I installed the 64 bit version of octave 6.3 with 64-bit indexing on a windows machine using the exe installer. I used C:\Octave to install it. No problems with directory permissions. C:\Temp is still usable. If it helps.

Anonymous
Thu 14 Oct 2021 08:58:45 AM UTC, comment #8: 

Similar problem here. New work computer. Installed octave with octave-6.3.0-w64-installer.exe on a computer running Windows 10 Pro (21H1). As I have no admin rights, installed it for my account only, no elevation. After installation, C:\Temp cannot be written to anymore, and all programs that use the Temp directory suffer. Apart from not being able to be written to anymore, more users have been added to C:\TEMP: NULL SID, CREATOR GROUP, Noone, CREATOR-OWNER (translated from German so it might not be spot-on: ERSTELLERGRUPPE, Kein, ERSTELLER-BESITZER). Windows reporting that the rights are in the wrong order.

Not completely certain if it is the octave installer, as I installed Fusion 360 and Python as well.

Peter Kruijt <p8r>
Mon 23 Aug 2021 05:18:48 AM UTC, comment #7: 

No response from the OP for more than a month.  Closing report.

If there is anything to add or the problem occurs again, please add more details and this report and it will be reopened again.

Kai Torben Ohlhus <siko1056>
Group Member
Wed 14 Jul 2021 06:09:15 PM UTC, comment #6: 

(I'm on Win10 Pro as well)
Thanks, I used to try tru the "Advanced system settings" dialog; your method works better here :-)  I lost track of that "usual way" since this dialog got moved to the Settings app a while ago.

Anyway, back to your issue. Any progress on your side?

Philip Nienhuis <philipnienhuis>
Group Member
Tue 13 Jul 2021 09:58:59 PM UTC, comment #5: 

comment #4:

> Again, curious:
> Just how did you change the user TMP (and TEMP - /typo?/) to D:\data\temp (from its default of %USERPROFILE%\AppData\Local\Temp)?
> As I wrote in the 4th bullet in my post I can't get that together for an entire user session. Not these days. So I'd be helped if someone can give me procedure for it :-)


You mentioned Windows 10 Home earlier, but as I said in my first comment I'm using Windows 10 Pro, could that be it?

It was a long time ago now that I changed that setting but I'm sure I just used the normal system properties dialogue box (the one with user variables on the top and system variables on the bottom, which you can get to e.g. by typing "environment variables" in to start menu search). It's been that way for many many reboots so it's not something that only applies to some programs or in a single session (clearly it applied to the Octave installer!). Both TEMP and TMP variables were present so I changed them both to be safe (both variables are also present in the system section, but as we've now established I didn't change those). As a test, I added a new environment variable in the system section and it didn't prompt me for UAC elevation, oddly, but it seemed to persist.

Arthur Tacca <arthur_tacca>
Tue 13 Jul 2021 07:29:12 PM UTC, comment #4: 

Again, curious:
Just how did you change the user TMP (and TEMP - /typo?/) to D:\data\temp (from its default of %USERPROFILE%\AppData\Local\Temp)?
As I wrote in the 4th bullet in my post I can't get that together for an entire user session. Not these days. So I'd be helped if someone can give me procedure for it :-)
The only way I can get close is to start up a CMD window and set TMP (TEMP) to "%APPDATA%\..\Local\Temp", and in that command window follow up with the applications that need that TMP (TEMP) setting.
That CMD session only changes the TMP (TEMP) setting in its copy of the Windows session environment, not for the entire Windows session it was spawned from.

AFAIU chkdsk doesn't check permissions in great detail - it focusses on the consistency of the MFT tables and file block occupations on the partition. But I could be wrong.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 13 Jul 2021 04:06:56 PM UTC, comment #3: 

Oh, I forgot one more thing: I did a chkdsk /R D: (I chose to do it at system restart when prompted to avoid any conflicts) and it did not find any problems.

Arthur Tacca <arthur_tacca>
Tue 13 Jul 2021 12:25:34 PM UTC, comment #2: 
  • Sorry, you're right that I have confused the user TEMP with system TEMP. In fact system TEMP (and TMP) is still set to its default of "%SystemRoot%\TEMP". I have changed the user TMP (and TMP) to D:\data\temp (from its default of %USERPROFILE%\AppData\Local\Temp). So of course it makes sense it only has normal user permissions.


  • Because I ended up installing Octave twice, there was very little in the second temp broken temp directory. There were a couple of files relating to Word and Outlook, an empty "PhotoCache" directory, and ... the uninstaller for Octave "D:\data\temp_2\~nsuA.tmp\Un_A.exe". After fixing permissions on the temp directory itself, only that uninstaller had its own individual permissions error.


  • Looking at the security dialog for affected directories, the problem seems to have something to do with permission type "Deny" and user "NULL SID". A quick Google points the finger at Cygwin. The results also suggest that the "incorrect order" is a result of Cygwin, but that it is intentional even though Explorer doesn't like it.


The last point explains why the permissions are a bit odd, but not why they are so broken that I can't read the files (which doesn't seem to be a commonly reported symptom) or why they were also changed on the temp directory itself (which wasn't created by the uninstaller). Maybe Cygwin + UAC elevation is a bad combination, but then (as you said) why isn't it affecting other people? Maybe the default temp directory has some extra protections? I'll try to do some more experiments later.

Arthur Tacca <arthur_tacca>
Mon 12 Jul 2021 09:39:30 PM UTC, comment #1: 

Quite an odd story.

Having poked a little in the Windows installer creation scripts, I fail to see how the Octave installer can change permissions of temp directories.
As Octave as been installed on probably many thousands of Windows systems and you are the very first person to mention just these specific issues, I'm rather inclined to think that there were already other issues in your system that merely got uncovered, not induced, by the Octave installer.
Maybe even any installer might induce them - can you try to install some other SW and see if you get similar problems? Preferably ones that also use NSIS installer SW.

Some notes about what you wrote:

  • Only in Windows Home edition the normal user has "some" potential admin credentials - nowadays also Microsoft understands baseline security so normal users never run with admin privileges anymore unless they click on some security popup (the notorious UAC thing).
  • I've seen the "rules in invalid order" myself several times (IIRC think it's "access permissions" rather than "rules") but that was when there were other issues with the NTFS volume in question. Oh and I couldn't get those "repaired" either - probably higher credentials than "administrator" are required, or starting the system in Safe mode.
  • (Maybe I didn't understand your description properly?) It's a very bad idea to fiddle with or in the system TEMP directory in the first place, let alone move it around. That directory is for system operation, not for mortal users.
  • I'm curious how you change your personal TEMP and TMP directory, other than by temporarily adapting the environment settings in a powershell or CMD window. Since a few Win10 releases only the SYSTEM and Administrator "TEMP" en "TMP" environment settings can be changed; the cause is that the pertinent system setting popup only applies to the user logged in for that popup and as that popup can only be reached as admin there's no way to change it for ordinary users anymore.


Maybe other Windows devs can chime in here?

Philip Nienhuis <philipnienhuis>
Group Member
Mon 12 Jul 2021 10:44:13 AM UTC, original submission:  

I installed GNU Octave 6.2.0 on Windows 10 Pro using the installer program octave-6.2.0-w64-installer.exe. I installed for all users, so the installer elevated to admin permission and successfully installed Octave. Almost immediately, odd problems started appearing throughout my system, including MS Outlook crashing when I attempted to open an attachment, Octave complained that it failed to set up local documentation, and the uninstaller for an old version of Octave (4.2.0) refused to run. (Incidentally I don't think I've had this problem before, so that indicates it must have been introduced some time after 4.2.0.)

I soon pinned down the problem: my system temporary directory had had its security permissions changed. I could see existing files in it but not create new ones. I use a temp directory on a different physical drive (D: rather than C:) so, unlike a normal Windows installation where the admin account is the owner (presumably?), the owner of my temp directory is just user level permission (because I made the directory myself and never specifically set the permissions). This had been changed to the point that when I opened the user permissions dialog in Explorer it complained about rules being in an invalid order so some wouldn't take effect, and asked if I would like to fix them - when I answered yes it then said there was an error attempting to do this. After fiddling for a while unsuccessfully, I ended up renaming the directory to something else and making a fresh directory with the original name. That seemed to fix all issues.

At this point I hadn't made the connection with the Octave installer (in fact I feared drive corruption) but I realised I had wanted to install Octave to a different place (my D: drive) so I uninstalled and reinstalled it. At that point the same thing happened again, so I think the installer must be the source of the problem.

Arthur Tacca <arthur_tacca>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by p8r (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by arthur_tacca (Submitted the item)
  •  

    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 group members can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-08-23 siko1056 Open/ClosedOpen Closed
    2021-08-20 jwe CategoryNone Configuration and Build System
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code