LeaseWatch.plist file being created with invalid permissions

[GoogleCodeExporter]

What steps will reproduce the problem?
1. New TunnelBlick install
2. Select the Set Nameserver Option
3. Connect

What is the expected output? What do you see instead?

The expected output is a successful vpn connection.

In /var/log/syslog with verb set to 4:

Nov 11 14:15:18 77 openvpn[1343]:
/Applications/Tunnelblick.app/Contents/Resources/client.up.osx.sh tun0 1500
1542 10.10.7.6 10.10.7.5 init
Nov 11 14:15:18 77 openvpn[1343]: MANAGEMENT: Client disconnected
Nov 11 14:15:18 77 openvpn[1343]: script failed: external program exited
with error status: 1
Nov 11 14:15:18 77 openvpn[1343]: Exiting

What version of Tunnelblick are you using? On what version of OS X? PPC or
Intel?

Mac OSX 10.5.8 (Intel)
Tunnelblick 3.0b22 (build 1246)

Please provide any additional information below.

The problem is shown when the up script for handling DNS settings runs.  If
one short-circuits the if statement towards the top to allow the script to
run outside the openvpn initialization environment, you see:

+ launchctl load
/Applications/Tunnelblick.app/Contents/Resources/LeaseWatch.plist
launchctl: Dubious permissions on file (skipping):
/Applications/Tunnelblick.app/Contents/Resources/LeaseWatch.plist
nothing found to load
+ exit 0

Looking at the permissions for LeaseWatch.plist, you see:
-rw-rw-rw-  1 root  wheel  509 Nov 11 14:44
/Applications/Tunnelblick.app/Contents/Resources/LeaseWatch.plist

Modifying the permissions to 644 resolves the problem

The VPN connection can be started from the GUI and all is well.  I also
noticed that the ~/Library/openvpn directory permissions are 777 which not
only makes no difference but makes no sense :)

Anyway, very cool program.  Thanks for your hard work!

Original issue reported on code.google.com by gladiat...@gmail.com on 11 Nov 2009 at 8:49

[GoogleCodeExporter]

This works for me.

You can't just run the up/down scripts outside of the environment they expect. 
That's really true of all scripts, I 
suppose. But they must run as root, and have other requirements. So I'm not 
surprised that you get odd results when 
you try.

You must run Tunnelblick at least once, and give an admin username/password, so 
that Tunnelblick can set the 
proper permissions on its components (such as LeaseWatch.plist). Having done 
that, LeaseWatch.plist and 
LeaseWatch.plist.template are both owned by root, with permissions 644, which 
is correct.

Each time you start Tunnelblick it checks ownership/permissions on its 
components and, if necessary, asks for an 
admin username/password and then repairs the permissions. (Similarly, it checks 
that configuration files are owned 
by root and have 744 permissions each time a connection is attempted.)

If you are running openvpnstart without first running Tunnelblick, that could 
cause lots of problems, including 
(perhaps) these. You must run Tunnelblick at least once before running 
openvpnstart so Tunnelblick sets up 
ownership/permissions correctly.

On my system, ~/Library/openvpn is owned by me, and has 755 permissions. Note 
that Tunnelblick doesn't create 
this folder, so I don't know what happened its permissions on your system.

Perhaps there is a larger problem with permissions on your system.

Original comment by jkbull...@gmail.com on 11 Nov 2009 at 9:49

[GoogleCodeExporter]

I'm sorry.  That was a detail I didn't include.  I did run the script as root.  
I did
so, also, after doing the initial tunnelblick execution to set up the 
environment.

The original problem was viewed in the Details window after having set up the
configuration/certs/keys/etc in the ~/Library/openvpn directory.

Unfortunately, I do not have access to a second Mac right now, so you may be on 
to
something regarding system-wide permissions.  There are no user-specific 
~/.bash*
files that would be setting a non-standard umask.  Frankly, I was able to 
create a
file (a simple "touch test.txt") and it was created with the expected 644
permissions.  My background is *NIX/BSD, so there might be something creeping 
about
in the Mac-specific internals of the system.  Dunno :P

After having run down this particular problem, I did uninstall then reinstall TB
thinking something might have gotten botched the first time; however, the 
results
were the same: rw-rw-rw on the .plist file and rwxrwxrwx on the 
~/Library/openvpn
directory.  There are no sticky bits or s/guid bits on the ~/Library directory 
either
that would cause a modification of the directory permissions.  The /Applications
directory also does not have any wonky permissions set that might cause this to 
occur. 

I'll probably create a fresh account tomorrow morning to see if I can reproduce 
this
error.

Thanks for your response!

Original comment by gladiat...@gmail.com on 11 Nov 2009 at 10:19

[GoogleCodeExporter]

Let me repeat: Tunnelblick does not create the ~/Library/openvpn folder. 
Tunnelblick has nothing to do with 
the permissions on that folder, or on anything in it except for configuration 
files that have been "used" by 
Tunnelblick. Those should be owned by root and haver permissions 644. (By 
"used" I mean you've tried to 
connect using them in Tunnelblick (NOT openvpnstart) and given an admin 
username/password so that 
Tunnelblick could set their ownership/permissions.)

Try this: copy Tunnelblick.app from the .dmg to your Desktop. Then use Terminal 
to check the permissions of 
stuff in ~/Desktop/Tunnelblick.app/Contents/Resources/ -- 
LeaseWatch.plist.template should be 644, 
leasewatch should be 755, and LeaseWatch.plist should not exist yet. Everything 
should be owned by you, not 
root.

Then launch this copy of Tunnelblick. Don't try to connect -- just launch it, 
give the admin 
username/password, and, when it appears next to the clock (almost instantly), 
quit.

Now the permissions should be: Leasewatch.plist.template 644 (same), leasewatch 
744, and LeaseWatch.plist 
should still not exist (it is created when you get to a certain point trying to 
connect with 'Set nameserver' 
checked). Everything should be owned by root.

Launch this copy of Tunnelblick and try to connect with 'Set nameserver' 
checked. (It doesn't matter if you are 
successful or not). The permissions on the configuration file you used to try 
to connect should be 644, and it 
should be owned by root.

Now check to see if the LeaseWatch.plist file exists, and, if so, what the 
ownership/permissions are. It should 
be owned by root:wheel, with permissions 644.

If everything was OK up to now but the permissions on LeaseWatch.plist are 
wrong, let us know. My 
understanding is that those permissions are the default permissions created by 
the following line near the 
end of the client.up.osx.sh script:
     sed -e "s|\${DIR}|${DIR}|g" "${LEASE_WATCHER}.template" > "${LEASE_WATCHER}"
which, at the time, is running as root.

Original comment by jkbull...@gmail.com on 12 Nov 2009 at 12:21

[GoogleCodeExporter]

Ok.  I ran TB from the desktop.  One step that it did want me to take was to
install/edit a demo config file.  Running from the desktop, it asked for an 
admin
user/pw.  I gave it one; however, it complained that it could not copy the demo 
.conf
file to ~/Library/openvpn.  (This is related to the default ACL perms on the
~/Library directory... apparently ACLs are relatively new to OSX?  Anyway...)

I updated the new account to be able to operate with admin privileges, logged 
out and
back in again and ran the TB app from the Desktop.  This time it properly 
created the
demo file in ~/Library/openvpn.  

After closing the demo openvpn.conf file, I exited the editor and then exited 
the TB
app from its control icon (by the clock)

At this point the permissions on the lease-related files are as you stated they
should be. (644/744/everything owned by root)  The Leasewatch.plist file does 
not
exist at this point.

I restarted the app, opened the details window, made sure the "Set Nameserver" 
box
was checked, and clicked "connect".  (typed admin password again)

At this point, the process died because the openvpn.conf doesn't describe 
enough of a
valid config to actually get to the point where it would run an up script 
(happens
after the tun device is brought up)

At this point, I copied my known, good openvpn config (complete with certs, 
keys, ca
bundle, etc) to ~/Library/openvpn.  The TB app shows the new config is in 
place.  I
opened the details window again, verified the Set Nameserver box was checked 
and hit
"connect".

The connection failed with:
script failed: external program exited with error status: 1

after trying to execute the script:
/Users/sdspence/Desktop/Tunnelblick.app/Contents/Resources/client.up.osx.sh 
tun0 1500
1542 10.10.7.6 10.10.7.5 init

At this point, I went back to my xterm to see that the Leasewatch.plist file 
has been
created thus:

-rw-rw-rw-  1 root  wheel      519 Nov 12 11:18 LeaseWatch.plist

Now, the key piece of the client.up.osx.sh script after the creation of the
Leasewatch.plist file is:

launchctl load "${LEASE_WATCHER}"

[/Users/sdspence/Desktop/Tunnelblick.app/Contents/Resources]
root@Macintosh-4: launchctl load LeaseWatch.plist 
launchctl: Dubious permissions on file (skipping): LeaseWatch.plist
nothing found to load

Modifying the permissions on this file (chown 644) actually makes things work.  
I
click connect, it negotiates the connection, sets the routes and name server and
gives me the glorious message of eternal OpenVPN happiness: Initialization 
Sequence
Completed 

:)

An observation regarding your last statement, the sed simply creates a file.  
What I
don't understand is why the file is created with those wonky permissions bits 
within
the openvpn context.

I'm already distributing a setup script for the Mac-using population to use when
installing TB (specifically to create an openvpn pseudo group/user).  It's no
travesty to include something to verify the permissions on this particular
troublemaker of a file; however, I just thought there might be something going 
on
with the context that TB is operating in when it's initializing its 
installation that
might need to be adjusted to avoid similar issues for others.

Original comment by gladiat...@gmail.com on 12 Nov 2009 at 5:44

[GoogleCodeExporter]

The permissions on your system are clearly messed up, or possibly there is 
something about your user's 
credentials/authority/something. Don't assume that's the case with your users 
-- this is the first time I've 
heard of a problem with Tunnelblick like this.

You mentioned "an openvpn pseudo group/user". Are you trying to run Tunnelblick 
as someone other than 
the logged-in user? I can see how that would cause problems -- it would 
probably cause problems with any 
program that creates files, because the creator of the files wouldn't be the 
logged-in user.

Are you fiddling Tunnelblick to start OpenVPN as something other than root? I 
can see how that would also be 
problematic, too.

Anyway, the "777" permissions on your ~/Library/openvpn are clearly wrong.  
Again, Tunnelblick had nothing 
to do with creating (or changing permissions on) either ~/Library or 
~/Library/openvpn. That's what makes 
me think your system has other problems.

You might want to check your ~/Library permissions, and re-create 
~/Library/openvpn and see what 
permissions you get then.

To give you an idea what is "normal", here are the permissions on ~/Library 
(via ls -l) on my 10.6.2 system:
     drwx------+ 44 <myUsername>  staff  1496 Nov  3 09:25 Library
and a "Get Info" shows:
     "<myUsername> has Read & Write"
     "everyone" has "No Access"

Here are the permissions on ~/Library/openvpn:
     drwxr-xr-x   17 <myUsername>  staff   578 Nov 12 14:34 openvpn
and a "Get Info" shows:
     "<myUsername> has Read & Write"
     "staff" has "Read only"
     "everyone" has "Read only"

If I create a new folder in ~/Library, either from the Finder using File | New 
Folder, or from Terminal.app using 
"mkdir", it has the same permissions as /Library/openvpn.

My 10.4.11 system shows identical ownership/permissions and "Get Info" data.

Original comment by jkbull...@gmail.com on 13 Nov 2009 at 1:56

[GoogleCodeExporter]

Marked as invalid because the problem is caused by misconfigured OS X 
permissions.

Original comment by jkbull...@gmail.com on 17 Nov 2009 at 4:46

• Changed state: Invalid