Permissions check is broken for MacOS Catalina (/tmp folder stored in System Volume)

[kevinschaich]

Hey, I'm running the MacOS Catalina developer beta (10.15 Beta (19A487l)) and I've spent way too many hours pulling my hair out over this issue. Hope we can investigate and fix before the public release this fall.

MacOS Catalina comes with a "dedicated system volume" which complicates permissions a bit:

When starting up Tunnelblick each time, I was granted with this message which you have to actively click "continue" through before using it:

This becomes a pain when you have Tunnelblick set up to start a server in the background on reboot, since it won't actually start until clicking continue here. I tried everything to fix this error, including the following resources:

• https://tunnelblick.net/cSystemFolderNotSecure.html
• https://eclecticlight.co/2017/06/15/something-odd-you-cant-fix-sierra-re-introduces-repairing-permissions/
• https://superuser.com/questions/1133065/unable-to-write-to-tmp-osx-unable-to-correct-permissions-operation-not-permitt

I believe this issue actually stems from this read-only "Data" partition in Catalina:

ls -lah /System/Volumes/Data/private/tmp
total 0
drwxrwxrwt  3 root  wheel    96B Jun 23 14:27 ./
drwxr-xr-x  6 root  wheel   192B Jun 23 14:26 ../
lrwxr-xr-x  1 root  wheel    12B Jun 23 14:27 tmp@ -> /private/tmp

It's impossible to change the permissions for this directory and running rm -rf /tmp and recreating it with the correct permissions as suggested in one of the above StackOverflow answers fails.

Is it possible to update Tunnelblick's default tmp directory checks to match the new permissions model in Catalina so we don't throw this error (which is a red herring)?

[jkbullard]

Thanks for reporting this, and for investigating so thoroughly and providing so much detail – very clear and helpful! (But I'm sorry you were pulling out your hair!)

This problem is fixed in not-yet-published commit 334ed86, which will be included in the next Tunnelblick beta release (later this week, I hope).

That commit fixes the check that Tunnelblick does on /tmp. The check failed because the group owner on Catalina is "admin". On all prior versions of macOS and OS X, it was "root". I assume the change was to help accommodate the new read only system volume which you noted. Other than this group ownership change, the read only system volume doesn't affect this check. I'm hoping it doesn't affect Tunnelblick at all, but we'll see…

I think this issue will be automatically closed when the commit is published to GitHub.

(Edited 2019-10-11 to correct the reference to the commit which fixed the problem, 334ed86.]

[jkbullard]

This is fixed in Tunnelblick 3.8.0beta03.

[kevinschaich]

Hey, thanks for fixing this so quickly. Really appreciate swift investigation & triage.

Thanks for a great project!

[georgemp]

Hi,

I'm seeing this issue with Tunnelblick 3.8.2 (build 5480) on macOS 10.15.3. The output of ls -l@ed /tmp ; ls -l@ed /private/tmp (from issue #579) is

lrwxr-xr-x@ 1 root  admin  11 Dec 29 01:46 /tmp -> private/tmp
	com.apple.rootless	 0
drwxrwxrwx  4 root  wheel  128 May  6 17:24 /private/tmp

If there is anything else you would like me to check (or if you would like me to open a new issue), do let me know. Thanks

[jkbullard]

@georgemp - An unmodified macOS 10.15.3 shows the following output from ls -l@ed /tmp ; ls -l@ed /private ; ls -l@ed /private/tmp:

lrwxr-xr-x@ 1 root  admin  11 Jan 26 12:49 /tmp -> private/tmp
	com.apple.rootless	 0 
drwxr-xr-x  6 root  wheel  192 Feb  4 05:36 /private
drwxrwxrwt  6 root  wheel  192 May  6 08:40 /private/tmp

Tunnelblick 3.8.2 works fine on it (and on 10.15.4) and doesn't complain.

Are you sure Tunnelblick is complaining about /tmp or /private/tmp? Please include a screenshot of the error window and if possible, relevant messages from the Console Log.

[georgemp]

Interesting. Here's a screenshot of the error message.

After quitting and relaunching, here are my logs

May  6 18:43:45  tunnelblickd[1342] <Debug>: approximateLastKnownReboot = 1588741534.976912; approximateMostRecentReboot = 1588741535.907608; difference = 0.930696
May  6 18:43:45  tunnelblickd[1342] <Debug>: This reboot time is approximately the same as the last reboot time; not first run after rebooting
May  6 18:43:45  tunnelblickd[1342] <Debug>: tunnelblickd invoked but not first run after reboot
May  6 18:43:45  tunnelblickd[1342] <Debug>: Started net.tunnelblick.tunnelblick.tunnelblickd
May  6 18:43:45  tunnelblickd[1342] <Info>: Created new temporary directory /var/folders/n0/3h8_k7ks5l38n6c5qg9mf62c0000gn/T/net.tunnelblick.tunnelblickd-GDCZ81
May  6 18:43:45  tunnelblickd[1342] <Info>: Removed temporary directory /private/var/folders/n0/3h8_k7ks5l38n6c5qg9mf62c0000gn/T/net.tunnelblick.tunnelblickd-GDCZ81
May  6 18:43:45  tunnelblickd[1342] <Info>: Created new temporary directory /var/folders/n0/3h8_k7ks5l38n6c5qg9mf62c0000gn/T/net.tunnelblick.tunnelblickd-VHs8Kh
May  6 18:43:45  tunnelblickd[1342] <Info>: Removed temporary directory /private/var/folders/n0/3h8_k7ks5l38n6c5qg9mf62c0000gn/T/net.tunnelblick.tunnelblickd-VHs8Kh
May  6 18:44:15  tunnelblickd[1342] <Debug>: Timed out; exiting

Before you spend too much time on this, I'm running this on a hackintosh with OpenCore. It might very well be an issue with my setup I guess.

[jkbullard]

@georgemp - I'm sorry and apologize: I failed to notice a missing "t" in the permissions of your /private/tmp. You wrote:

drwxrwxrwx  4 root  wheel  128 May  6 17:24 /private/tmp

I wrote that it should be:

drwxrwxrwt  6 root  wheel  192 May  6 08:40 /private/tmp

But I failed to note the difference. You can repair this problem with

sudo chmod 01777 /private/tmp

(That's part of a command shown on System Folder Security; you don't need the rest of the command because the ownership of /private/tmp is OK.)

I can't say with certainty that some of the hackintosh support software is responsible for the incorrect permssions, but that would be my assumption. Similarly, I assume that setting the permissions to the correct value won't interfere with the hackintosh support software, but I can't be certain.

Details

Tunnelblick checks that /private/tmp is owned by root:wheel (0:0) and has permissions of 1777 (octal). These ownership and permission values were obtained by clean installs of various versions of macOS.

The first octal digit (in this case "1") is rarely seen and is ignored in almost all discussions of permissions, which focus on the read/write/execute permissions held in the last three octal digits (in this case "777"). The "1" in the "1777" refers to the "sticky bit". man 2 chmod says:

If mode ISVTX (the `sticky bit') is set on a directory, an unprivileged user may not delete or rename files of other users in that directory. The sticky bit may be set by any user on a directory which the user owns or has appropriate permissions. For more details of the properties of the sticky bit, see sticky(7).

man stickysays:

A directory whose `sticky bit' is set becomes an append-only directory, or, more accurately, a directory in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files.

[jkbullard]

@georgemp - About the log you posted: That log (/var/log/Tunnelblick/tunnelblickd.log) is for "tunnelblickd", which is a privileged daemon that Tunnelblick uses to perform certain operations that require root privileges. The Tunnelblick program logs to the normal system log. See The Console Log for details about that log.

[georgemp]

Thanks for the quick reply. The logs from system log are

May  6 17:24:09 iMac Tunnelblick[819]: Tunnelblick: macOS 10.15.3; Tunnelblick 3.8.2 (build 5480)
May  6 17:24:09 iMac Tunnelblick[819]: /private/tmp does not have the required (permissions = 0777; require 01777)

Running sudo chmod 01777 /private/tmp seems to have fixed the issue :)

Logs after running the command

May  6 20:58:55 iMac Tunnelblick[1606]: Tunnelblick: macOS 10.15.3; Tunnelblick 3.8.2 (build 5480)
May  6 20:58:57 iMac Tunnelblick[1606]: Sparkle: ===== Tunnelblick =====
May  6 20:58:57 iMac Tunnelblick[1606]: Sparkle: Verified appcast signature