Install tunnelblick for non-admin users

[arjen.van...@gmail.com]

I'm managing Macs for people that don't have admin privileges. How can I bootstrap tunnelblick so that they don't get the dialog asking for admin credentials?

[jkbull...gmail.com]

I'm not sure what you mean by "bootstrap" -- is that different from "install"?

A computer admin is required to install the Tunnelblick program itself and to install VPN configurations. There is no way around that if the system on which Tunnelblick is being installed is to remain secure.

Once the program and configurations have been installed, however, a non-admin user can connect and disconnect from the VPN and perform other actions that don't have security implications.

In other words, a computer admin must "set up" Tunnelblick, but after that a non-admin user can "use" Tunnelblick.

Authorization by a computer admin is required because some parts of Tunnelblick run code as "root", and to prevent escalation of privileges attacks, a computer admin must authorize most changes that would modify what that code does.

I (or anyone) could create a way for a computer admin to install Tunnelblick from the command line (with a "sudo" command). That doesn't exist now. I haven't created such a way to do that because It isn't clear to me what use that would be.

Another approach would be to create an "installer package". My understanding is that such a package would facilitate remote install/uninstall in some way, but I'm not clear about how.

[arjen.van...@gmail.com]

In my environment, installing is copying the application bundle to /Applications (as tunneblick does not come with a pkg installer). So bootstrap would involve setting up permissions, launchd, etc. Our software distribution method (https://github.com/munki/munki) allows for postflight scripts to run (as root) after the app has been copied.

My question is: what script should I run as root to setup tunnelblick for a non-admin user?

 

[jkbull...gmail.com]

You'd have to create either a .pkg installer, or create a postflight script. Because you are using open source software such as Tunnelblick, it would also be nice if you shared your creations with the rest of us.

The code that installs Tunnelblick is in the "installer.m" Objective-C source code; you should refer to that for the definitive description of what needs to be done.

A postflight script would have to do the following to secure Tunnelblick.app itself:

chown -R 0:0 /Applications/Tunnelblick.app

The script would also need to create a bunch of folders used by Tunnelblick and copy tunnelblick.plist to /Library/LaunchDaemons. I think that's all.

(It may sound odd, but the best way to find out what changes installation of Tunnelblick does to a system is probably to first install it, then use the Tunnelblick Uninstaller program to uninstall it and get the "details" of the uninstall. The details list what was removed, which tells you what was installed.)

 All that the above would do is install the Tunnelblick program; it does not install any configurations.

Configurations are a bit tricky because although Tunnelblick allows a lot of flexibility in a configuration before it is installed (the "input" to the Tunnelblick configuration installer), they have a fairly rigid structure after installation (the "output" from the Tunnelblick configuration installer). And installed configurations can live in several places: private configurations live in ~/Library/Application Support/Tunnelblick/Configurations/ but have a companion "secure" copy in /Library/Application Support/Tunnelblick/Users/username/; shared configurations have only a "secure" copy in /Library/Application Support/Tunnelblick/Shared/. Configurations are standard OS X "bundles", with a "Contents" and "Resources" folder and an optional Info.plist.

You would have to create your own script to install configurations. It would have to

1. Copy the configurations from (somewhere) to the proper folder (and create the "secure" copy if it was a private configuration).
   
2. Set ownership of the copied configurations appropriately; and
   
3. Set permissions of the copied configurations appropriately.
   

where "appropriately" varies with the location of installation. The code that secures a configuration is complex because the different parts of a configuration require different protections. For example, only the user has access to the private configuration, but everyone has access to some parts of a "shared" configuration and only root has access to other parts of a shared configuration. Probably the best way to get the ownership/permissions correct is to have Tunnelblick install the configuration(s) and then use the installed configurations as templates.

[goo...@gerardkok.nl]

I'm also trying to distribute Tunnelblick using Munki, and my postinstall script currently looks like this:

#!/bin/sh

/Applications/Tunnelblick.app/Contents/Resources/installer 5

/bin/launchctl load -w /Library/LaunchDaemons/net.tunnelblick.tunnelblick.tunnelblickd.plist

This seems to work reasonably well, although I haven't tested it thoroughly. Tbh I don't fully understand why the launchd job needs to be started in the postinstall script (as it's also started in the Resources/installer binary).

[jkbull...gmail.com]

Excellent!

Of course using Tunnelblick's "installer" is the way to do this. I have no idea why that didn't even occur to me -- a total brain malfunction, apparently.

Tunnelblick's installer can help install configurations, too:

1. Run "installer 5" and "launchctl..." to get all needed folders set up (in /Library/Application Support, etc.) and secure the Tunnelblick application itself.
   
   
2. Run the "launchctl" command, too. I don't understand why it would be needed, since the installer should run that command, but it won't do any harm.
   
   
3. Copy configurations into /Library/Application Support/Tunnelblick/Shared/ (for shared configurations) or ~/Library/Application Support/Tunnelblick/Configurations/ (for private configurations).
   
   
4. Run "/Applications/Tunnelblick.app/Contents/Resources/installer 16"
   

The last command will "secure" the configurations. That is, it will set ownership and permissions. It will not modify the content of the configuration. (It will, however, create a secure "shadow" copy of each private configuration.)

Installing configurations this way requires that they be created in specially structured folders. The normal GUI-based installation does a lot of error checking and allows configurations to be unstructured, but you would be bypassing this.

Each configuration should look like this (for a configuration named "Foo bar"):

     Foo bar.tblk/

          Contents/

               Resources/

                    config.ovpn

The "Resources" folder should also contain any other files needed by the configuration (such as key or certificate files), and those files should be referred to within the config.ovpn file without any path information. An optional "Info.plist" file may be included in the "Contents" folder.

For more information about the contents of a .tblk, see Tunnelblick VPN Configurations Details.

For more information about the meaning of the first argument to "installer", see installer.m and the "Bit masks for bitMask parameter of installer" section of defines.h in the source code.

[stue...@gmail.com]

My Munki postinstall script looks like this:

#!/bin/sh
/Applications/Tunnelblick.app/Contents/Resources/installer 5

/bin/launchctl load -w /Library/LaunchDaemons/net.tunnelblick.tunnelblick.tunnelblickd.plist

/Applications/Tunnelblick.app/Contents/Resources/installer 16

Tunnelblick still asks for admin credentials. Perhaps I have overlooked something?
I would realy appreciate if someone could shed some light on this topic.

[jkbull...gmail.com]

Hmmm. This involves a new feature (introduced into the source code in commit Force reload of tunnelblickd after application updates on 2016-04-28, first appearing in a release in Tunnelblick 3.6.3 build 4560 on 2016-05-03.

The feature makes sure that the Tunnelblick launchd daemon that is currently loaded by OS X is the same as the daemon that is in the currently running Tunnelblick. This is needed because an update of Tunnelblick (using Sparkle Updater) does not load the (possibly newer) daemon.

The way it was implemented was to store a hash of the daemon and a hash of the .plist that is used to launch the daemon. Those hashes are checked each time Tunnelblick launches; if they don't match, the user is asked for authorization to reload the daemon from the current application. (The hashes are stored in the user's preferences by the main Tunnelblick code after a successful install.)

I now see that that this implementation is problematic for several reasons. My first ideas to fix this are to have the installer itself update the hash into a secure location and perhaps have Sparkle force the daemon to be updated, but I will have to think about it some more.

I will start working on this right away and will report back to this thread when it is resolved. (This is a high priority for me; I expect it will appear in the next beta.)

PS: I think that, because of this new feature, the "launchctl load" in your script is no longer needed.

[goo...@gerardkok.nl]

I noticed this too, and have adapted our postinstall script to compute the relevant hashes, and store them in net.tunnelblick.tunnelblick.plist of the user using Tunnelblick. In our environment, we have precisely one user per machine (which is possible to retrieve in the postinstall script), so it's possible to know which net.tunnelblick.tunnelblick.plist file to put the hashes in. If you know which net.tunnelblick.tunnelblick.plist files to write to in the tunnelblick postinstall script, you might use this as a workaround.

For completeness, this is the part of our postinstall script that computes the hashes, and puts them in the correct net.tunnelblick.tunnelblick.plist:

tunnelblickd_hash=`/usr/bin/shasum -a 256 /Applications/Tunnelblick.app/Contents/Resources/tunnelblickd | awk '{print $1}'`

tunnelblickd_plist_hash=`/usr/bin/shasum -a 256 /Library/LaunchDaemons/net.tunnelblick.tunnelblick.tunnelblickd.plist | awk '{print $1}'`

/usr/bin/defaults write /Users/<user>/Library/Preferences/net.tunnelblick.tunnelblick.plist tunnelblickdHash -string ${tunnelblickd_hash}

/usr/bin/defaults write /Users/<user>/Library/Preferences/net.tunnelblick.tunnelblick.plist tunnelblickdPlistHash -string ${tunnelblickd_plist_hash}

/usr/sbin/chown <user>:staff /Users/<user>/Library/Preferences/net.tunnelblick.tunnelblick.plist*

[jkbull...gmail.com]

An update:

I have committed changes to the source code to fix this up so Tunnelblick deals with its LaunchDaemon properly. Whenever the Tunnelblick installer is run it makes sure the installed LaunchDaemon matches the one in the copy of Tunnelblick that is running. If not, it updates the LaunchDaemon's .plist and reloads the LaunchDaemon. So this is done when you initially install Tunnelblick, install a configuration, etc.

When Tunnelblick is launched and sees that its LaunchDaemon is not the same as the LaunchDaemon that is installed, Tunnelblick will prompt the user for admin credentials to "Complete the update". (That's because when Tunnelblick is updated via its built-in updater the LaunchDaemon is not dealt with. At some point I hope to fix the updater so that it deals with the LaunchDaemon, and at that point this will stop happening.)

These changes will be included in the next beta, which I expect to release within a week.

[Mathieu]

Thanks for this.

I noticed that if I use a script similar to what goo...@gerardkok.nl posted, it works. So it seems on initial run, if no hash info is present in the users preferences section, tunnelblick will ask for admin cred to reload tunnelblickd. I don't think this is correct behavior. TB should only ask for a reload if there is a  mismatch of the hashes; not absent hashes which could be written  to the user's prefs without admin privs.

[jkbull...gmail.com]

The old way of handling hashes was bad for several reasons, including the fact that it shouldn't have anything to do with the user and a non-admin user shouldn't be able to tamper with them.

The new way is that when the (privileged) installer program sets up the LaunchDaemon, it stores the hashes as protected files in /Library/Application/Support/Tunnelblick. If needed, this is done whenever installer is run (for example, when a script invokes the Tunnelblick installer program to install Tunnelblick).

If the hashes are missing or aren't what is expected when Tunnelblick is launched, then the user is asked for admin credentials to "Complete the update". and the LaunchDaemon .plist is installed from the "model" copy in Tunnelblick.app. That should only happen after an update via Tunnelblick's mechanism. (Note that you need to supply admin credentials to do the update, so whoever does the update needs to know them anyway. And I hope to remove the need for that second request for admin credentials at some point by making the update mechanism update the LaunchDaemon and hashes.)

I have also occasionally considered allowing Tunnelblick to be updated without requiring admin credentials (once it has been installed, which will always require admin credentials). Now that I have implemented "admin only" preferences (used by the "Require admin authorization for key and certificate changes" checkbox), that would be reasonably easy to do so, if there is interest.

[Mathieu]

> The new way is that when the (privileged) installer program sets up the LaunchDaemon, it stores the hashes as protected files in /Library/Application/Support/

Tunnelblick. 
 
Excellent! Thanks!

> I have also occasionally considered allowing Tunnelblick to be updated without requiring admin credentials (once it has been installed, which will always require admin credentials). Now that I have implemented "admin only" preferences (used by the "Require admin authorization for key and certificate changes" checkbox), that would be reasonably easy to do so, if there is interest.
 

I personally wouldn't want this. Since we manage software in our organization, we want to keep them at specific versions and roll out program updates only after testing/staging. But it might be a useful option for some people. As long as there is an option to turn this on or off at install time and in system config, then it should work for everyone.

[Mathieu]

What are the installer number codes? (eg, 5, 16).  I can't seem to find this documented anywhere.

[jkbull...gmail.com]

They aren't documented (installer wasn't designed to be used outside of the Tunnelblick program itself), but the source code of defines.h has them:

#define INSTALLER_CLEAR_LOG                  0x0001u

#define INSTALLER_COPY_APP                   0x0002u

#define INSTALLER_SECURE_APP                 0x0004u

//                                           0x0008u  UNUSED, was "INSTALLER_HELPER_IS_TO_BE_SUID"

#define INSTALLER_SECURE_TBLKS               0x0010u

#define INSTALLER_CONVERT_NON_TBLKS          0x0020u

#define INSTALLER_MOVE_LIBRARY_OPENVPN       0x0040u

#define INSTALLER_INSTALL_FORCED_PREFERENCES 0x0080u

#define INSTALLER_REPLACE_DAEMON             0x0100u

#define INSTALLER_MOVE_NOT_COPY              0x1000u

#define INSTALLER_DELETE                     0x2000u

The last two are used to move/copy or delete configurations. The first part of installer.h describes its arguments. You can see the current version (as of today) at https://github.com/Tunnelblick/Tunnelblick/blob/088b243fa925ab625a90b36ea88977095092c966/tunnelblick/installer.m

Note that the comments may not be completely up-to-date and in sync with what the code actually does.

[jkbull...gmail.com]

The changes are included in just-released Tunnelblick 3.6.6beta02.

[John Lockwood]

A couple of jobs ago and hence a few years ago I was using Tunnelblick and responsible for deploying the Tunnelblick client to Macs and I used a post install script which included the commands

/Applications/Tunnelblick.app/Contents/Resources/installer 5

/Applications/Tunnelblick.app/Contents/Resources/installer 16

This at the time worked fine for me in that users did not get asked to enter an admin password after Tunnelblick was installed or a newer version was installed.

Unfortunately this does not seem to be working right now. If I use the same post install script, the installation works, it even 'restores' a tunneblick.tblk directory in to /Library/Application Support/Tunnelblick/Shared and the final lines in the script are to run the above two installer commands. However when I launch Tunnelblick as normal it asks for an admin password. The fact the .tblk is being restored confirms the post install script did run.

If I cancel that admin password request and then in terminal manually execute the same commands then it DOES fix this and it no longer asks for an admin account.

Any ideas? I am now running under macOS Ventura and Apple have had a nasty habit of breaking automated admin functions. 

Is there any log or other diagnostic info I can provide to help diagnose this? It seems to be installer 5 that is the issue. Once I manually run that it launches fine and the restored .tblk also works fine with no permissions problem.

Note: macOS Ventura 13.4 and Tunnelblick 3.8.8b being used on a MacBook Air 13" M1 2020.

[Tunnelblick developer]

The installer log is at /tmp/tunnelblick-installer-log.txt and should contain useful information.

The problem may be that installer is being started in such a way that it cannot determine which user's configurations should be secured.

installer uses getuid() to specify which user is running installer.

When started by Tunnelblick, installer runs with geteuid() of 0, and getuid() of the user that is running Tunnelblick.

However, when started with both geteuid() and getuid() equal to 0, installer can't determine the user whose configurations are to be secured.

The installer's log at /tmp/tunnelblick-installer-log.txt should tell you the getuid() and geteuid() it was started with, and if that's the problem, may display a "Tunnelblick internal error: secureOneFolder: No user" or similar error.

Tunnelblick 4.0.0 will have a new mechanism that uses clues from the working directory and/or paths in the installer command to determine the user, and adds commands to install private and shared configurations. (4.0.0beta06 has a partial implementation of that, but has a bug: not detecting the username from the working directory properly.)  It may be a good idea to also add an additional command to secure .tblks that would include a username. I'll think about that.

[Gerard Kok]

I noticed similar issues since Tunnelblick 3.8.8 (or perhaps 3.8.8.a). We're using Munki to deploy Tunnelblick, and we could fix it by giving the Munki installer Full Disk Access (i.e. for older versions of Munki that meant giving access to Munki's python, but nowadays it's the managedsoftwareupdate binary).

[John Lockwood]

@Tunnelblick developer

I had a look at the log and indeed geteuid() and getuid() both reported as 0. As per -

Tunnelblick installer started 2023-06-13 18:26:01.617908. 1 arguments: 0x0005

getuid() = 0; getgid() = 0; geteuid() = 0; getegid() = 0

I also spotted the following in the log which may or may not be significant.

Unable to change ownership of /Applications/Tunnelblick.app from 0:80 to 0:0

Error was 'Operation not permitted'

Unable to change permissions from 755 to 744 on /Applications/Tunnelblick.app/Contents/Resources/atsystemstart

...

Unable to change permissions from 755 to 744 on /Applications/Tunnelblick.app/Contents/Resources/re-enable-network-services.sh

Unable to change ownership of /Applications/Tunnelblick.app/Contents/Resources/openvpn from 0:80 to 0:0

Error was 'Operation not permitted'

On a related topic I discovered that with macOS Ventura 13.0 during the beta program Apple introduced a new security control of apps in /Applications being modified. See these articles.

https://community.jamf.com/t5/jamf-pro/ventura-quot-app-management-quot/td-p/283396 https://groups.google.com/g/munki-dev/c/yRKhUGjNibY/m/eZ91OxZ5AAAJ https://macmule.com/2022/10/24/macos-ventura-and-bypassing-the-new-systempolicyappbundles-privacy-policy-control/

I am wondering if this is related. If so you may have to sign your app and do some other changes. I am attaching the entire log for you to review.

Would it not be possible for you to set the permissions and ownership on your app correctly in the first place so they don't need to be changed!

I am only using a shared Tunnelblick config, not individual ones, so have no need to 'trust' individual ones or any individual files. As indicated also by @Gerard Kok I am also using Munki and this did work for me in the past. I will try his suggestion of giving the Munki binaries Full Disk Access.

[John Lockwood]

Whilst I had in my post-install script the usual commands as below, as per my report this was not proving sufficient to result in a fully automated install with no need for a user to provide admin authorisation.

/Applications/Tunnelblick.app/Contents/Resources/installer 5
/Applications/Tunnelblick.app/Contents/Resources/installer 16

I found that adding all the following has however achieved this.

/usr/sbin/chown -R root:wheel "/Library/Application Support/Tunnelblick/Shared"

/usr/sbin/chown -R 0:0 "/Applications/Tunnelblick.app"

/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/atsystemstart"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/installer"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/leasewatch"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/leasewatch3"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/process-network-changes"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/standardize-scutil-output"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/tunnelblickd"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/client.route-pre-down.tunnelblick.sh"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/client.1.up.tunnelblick.sh"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/client.1.down.tunnelblick.sh"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/client.2.up.tunnelblick.sh"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/client.2.down.tunnelblick.sh"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/client.3.up.tunnelblick.sh"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/client.3.down.tunnelblick.sh"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/client.4.up.tunnelblick.sh"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/client.4.down.tunnelblick.sh"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/re-enable-network-services.sh"
/bin/chmod 755 "/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.18-libressl-2.7.1/openvpn"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.18-libressl-2.7.1/openvpn-down-root.so"
/bin/chmod 755 "/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.18-openssl-1.0.2u/openvpn"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.18-openssl-1.0.2u/openvpn-down-root.so"
/bin/chmod 755 "/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.4.12-openssl-1.1.1u/openvpn"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.4.12-openssl-1.1.1u/openvpn-down-root.so"
/bin/chmod 755 "/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.5.9-openssl-1.1.1u/openvpn"
/bin/chmod 744 "/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.5.9-openssl-1.1.1u/openvpn-down-root.so"

/usr/sbin/chown -R 0:0 "/Applications/Tunnelblick.app/Contents/Resources/openvpn"

[Tunnelblick developer]

@John Lockwood - Thanks. I gather you are not using Munki.

Yes, you can certainly do the work of Tunnelblick's installer separately. But that will be fragile; we often make changes that would break doing that. For example, versions of OpenVPN change regularly.

But I'm puzzled as to why you need to make any permissions changes within Tunnelblick.app. Everything in Tunnelblick should have the correct permissions, it is only the ownership that must change to 0:0. For example, if I mount the Tunnelblick disk image:

% cd /Volumes/Tunnelblick/Tunnelblick.app/Contents/Resources
% ls -l atsystemstart installer leasewatch* re-enable-network-services.sh
-rwxr--r--  1 <username>  staff  297984 Jun  3 16:45 atsystemstart
-rwxr--r--  1 <username>  staff  535744 Jun  3 16:45 installer
-rwxr--r--  1 <username>  staff    7537 Jun  3 14:48 leasewatch
-rwxr--r--  1 <username>  staff    7525 Jun  3 14:48 leasewatch3
-rwxr--r--  1 <username>  staff    2069 Jun  3 14:48 re-enable-network-services.sh

Also, why would you need to do

/usr/sbin/chown -R 0:0 "/Applications/Tunnelblick.app/Contents/Resources/openvpn"

after you've done

/usr/sbin/chown -R 0:0 "/Applications/Tunnelblick.app"

?

[John Lockwood]

I am actually using Munki and have put these extra chmod commands in the post-install phase.

You are right about the unnecessary extra chown command. As you saw from the log I uploaded it was complaining about all the permissions so having added all the extra chmod entries it no longer has those complaints.

As per the new log below

Tunnelblick installer started 2023-06-14 13:13:57.540977. 1 arguments: 0x0005

getuid() = 0; getgid() = 0; geteuid() = 0; getegid() = 0

Changed ownership of /Library/Application Support/Tunnelblick from 0:80 to 0:0

Created directory /Library/Application Support/Tunnelblick/Logs with owner 0:0 and permissions 755

Created directory /Library/Application Support/Tunnelblick/Tblks with owner 0:0 and permissions 755

Created directory /Library/Application Support/Tunnelblick/Mips with owner 0:0 and permissions 755

Created directory /Library/Application Support/Tunnelblick/expect-disconnect with owner 0:0 and permissions 755

Created directory /Library/Application Support/Tunnelblick/Users with owner 0:0 and permissions 755

Created directory /Library/Application Support/Tunnelblick/Users/root with owner 0:0 and permissions 755

Created or checked '/var/root/Library/Application Support/Tunnelblick'; owner = 0:80; permissions = 488

Created or checked '/var/root/Library/Application Support/Tunnelblick/Configurations'; owner = 0:80; permissions = 488

Need to replace and/or reload 'tunnelblickd':

    tunnelblickdHashOK   = NO

    launchctlPlistHashOK = NO

    tunnelblickdPlistOK  = YES

    socketOK             = YES

Replaced /Library/LaunchDaemons/net.tunnelblick.tunnelblick.tunnelblickd.plist

Used launchctl to load tunnelblickd

Tunnelblick installer finished without error

stat of /tmp/tunnelblick-authorized-error failed

Error was 'No such file or directory'

stat of /tmp/tunnelblick-authorized-running failed

Error was 'No such file or directory'

Tunnelblick installer started 2023-06-14 13:13:58.098614. 1 arguments: 0x0010

getuid() = 0; getgid() = 0; geteuid() = 0; getegid() = 0

Created or checked '/var/root/Library/Application Support/Tunnelblick'; owner = 0:80; permissions = 488

Created or checked '/var/root/Library/Application Support/Tunnelblick/Configurations'; owner = 0:80; permissions = 488

Tunnelblick internal error: secureOneFolder: No user

Warning: Unable to secure all .tblk packages

Tunnelblick installer finished without error

stat of /tmp/tunnelblick-authorized-error failed

Error was 'No such file or directory'

stat of /tmp/tunnelblick-authorized-running failed

Error was 'No such file or directory'

I am still wondering if the new macOS Ventura PPPC control as per https://macmule.com/2022/10/24/macos-ventura-and-bypassing-the-new-systempolicyappbundles-privacy-policy-control/ may have relevance.

[Tunnelblick developer]

> I am actually using Munki and have put these extra chmod commands in the post-install phase.

It must be Munki that is copying the files with incorrect permissions, then. That's very bad; they should be copied as they are.

Here are my comments on your logs:

Tunnelblick installer started 2023-06-14 13:13:57.540977. 1 arguments: 0x0005

getuid() = 0; getgid() = 0; geteuid() = 0; getegid() = 0

Changed ownership of /Library/Application Support/Tunnelblick from 0:80 to 0:0

     Are you updating an old system? Tunnelblick has required 0:0 ownership for quite a while.

Created directory /Library/Application Support/Tunnelblick/Logs with owner 0:0 and permissions 755

Created directory /Library/Application Support/Tunnelblick/Tblks with owner 0:0 and permissions 755

Created directory /Library/Application Support/Tunnelblick/Mips with owner 0:0 and permissions 755

Created directory /Library/Application Support/Tunnelblick/expect-disconnect with owner 0:0 and permissions 755

Created directory /Library/Application Support/Tunnelblick/Users with owner 0:0 and permissions 755

Created directory /Library/Application Support/Tunnelblick/Users/root with owner 0:0 and permissions 755

     The above is necessary and appropriate.

Created or checked '/var/root/Library/Application Support/Tunnelblick'; owner = 0:80; permissions = 488

Created or checked '/var/root/Library/Application Support/Tunnelblick/Configurations'; owner = 0:80; permissions = 488

     This is because getuid() == 0. Tunnelblick 4.0.0 should avoid doing this.

Need to replace and/or reload 'tunnelblickd':

    tunnelblickdHashOK   = NO

    launchctlPlistHashOK = NO

    tunnelblickdPlistOK  = YES

    socketOK             = YES

Replaced /Library/LaunchDaemons/net.tunnelblick.tunnelblick.tunnelblickd.plist

Used launchctl to load tunnelblickd

     The above are necessary and appropriate.

Tunnelblick installer finished without error

stat of /tmp/tunnelblick-authorized-error failed

Error was 'No such file or directory'

stat of /tmp/tunnelblick-authorized-running failed

Error was 'No such file or directory'

     These are flag files used by Tunnelblick when it runs installer. The errors can be ignored.

Tunnelblick installer started 2023-06-14 13:13:58.098614. 1 arguments: 0x0010

getuid() = 0; getgid() = 0; geteuid() = 0; getegid() = 0

Created or checked '/var/root/Library/Application Support/Tunnelblick'; owner = 0:80; permissions = 488

Created or checked '/var/root/Library/Application Support/Tunnelblick/Configurations'; owner = 0:80; permissions = 488

Tunnelblick internal error: secureOneFolder: No user

Warning: Unable to secure all .tblk packages

     Since it doesn't know what user's .tblk packages should be secured, it can't secure them.

Tunnelblick installer finished without error

    Well, for some definition of "error" : ). I'll look into why it doesn't complain about not securing the .tblks, though.

stat of /tmp/tunnelblick-authorized-error failed

Error was 'No such file or directory'

stat of /tmp/tunnelblick-authorized-running failed

Error was 'No such file or directory'

     These are flag files used by Tunnelblick when it runs installer. The errors can be ignored.