Tunnelblick will not start connection with NFS mounted home directory.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. NFS mounted home directory on Leopard/Tiger
2. Start tunnelblick
3. Attempt to 'Connect' to server.

What is the expected output? What do you see instead?
The expected output is connection information in the OpenVPN log.  Instead
nothing is in the VPN log and instead and error is logged to the system log.  

These same configuration files and versions work fine using laptops or
other non NFS mounted directories. 

What version of the product are you using? On what operating system?
Using the latest version of Tunnelblick 3.0b9 also tested older versions.
Leopard and Tiger behave the same.

Please provide any additional information below.

The errorlog on the host is:
hostname [0x0-0xea0ea].com.openvpn.tunnelblick[5791]: 2008-11-19
15:20:46.383 openvpnstart[9832:10b] File
/home/nfs/user/Library/openvpn/connection.conf has permissions: 0, is owned
by (null) and needs repair...
hostname [0x0-0xea0ea].com.openvpn.tunnelblick[5791]: 2008-11-19
15:20:46.386 openvpnstart[9832:10b] Config File needs to be owned by
root:wheel and must not be world writeable.

---

The file is owned by root:wheel as confirmed by ls.

Original issue reported on code.google.com by dean.jo...@gmail.com on 19 Nov 2008 at 10:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I can confirm to have the same issue with OS-X 10.5.6-client, 
Tunnelblick_3.0b10:

1) vpn-connection can be established on a local account,

2) but an account of a net-user (=>homedir on a afp-mounted sharepoint) will be
facing the identical issue as mentioned above, even if that user has local
administrative privileges.

Notabene: 
1) Tunnelblick installation and config has proven to be fine & healthy for local
accounts.
2) on 10.4.x-clients this has not be a problem

I would like to raise the priority to urgent, but thats a very individual view, 
as i
know.

Best regards...

Original comment by hilmarfr...@gmx.de on 27 Jan 2009 at 3:56

[GoogleCodeExporter]

I don't know how to change the priority level of the bug.

Original comment by dean.jo...@gmail.com on 23 Feb 2009 at 9:30

[GoogleCodeExporter]

Fixed in trunk as r81.

Original comment by jkbull...@gmail.com on 20 May 2009 at 4:01

• Changed state: Fixed

[GoogleCodeExporter]

I am still having issues with this bug, even after doing a fresh build from the 
code
in the trunk.

Now i get a pop up box complaining about permissions on the conf file, and 
telling
tunnelblick to continue gets this message:

Jun  3 15:24:07 hostname [0x0-0x585585].com.openvpn.tunnelblick[70364]: Error:
/home/directory/user/Library/openvpn/network.conf does not exist

I have tried all manner of permissions and ownership of this file with no 
change in
behavior.
thanks

Original comment by dean.jo...@gmail.com on 3 Jun 2009 at 10:27

[GoogleCodeExporter]

Trunk r92 now has second try at fixing this. 

Original comment by jkbull...@gmail.com on 4 Jun 2009 at 5:04

[GoogleCodeExporter]

Thanks for the update.

The error no longer appears in systemlog, but Tunnelblick will not attempt a
connection.  No text in the details window.

Turning up the log level does not reveal any kind of logs, unless i'm not doing 
the
log thing right.

Original comment by dean.jo...@gmail.com on 9 Jun 2009 at 5:03

[GoogleCodeExporter]

Another try at fixing this problem. (Since I don't have a setup that can put a 
home folder on a network 
volume, it's a bit of a shot in the dark.)

r117 implements a preference that may make this work. Usually, Tunnelblick 
monitors the ~/Library/openvpn 
folder to detect changed/added/deleted configuration files. It is possible that 
the monitoring is causing the 
problem. In any case, it was easy to make it optional.

Monitoring is turned on by default.

To turn if off, type the following into Terminal before starting Tunnelblick:

     defaults write com.openvpn.tunnelblick doNotMonitorConfigurationFolder -bool true

and to restore monitoring, close Tunnelblick and type the following into 
Terminal:

    defaults delete com.openvpn.tunnelblick doNotMonitorConfigurationFolder

So try r117 with the preference set true (if you haven't lost patience 
already!) and let us know.

Of course, with the monitoring off, you might need to quit and restart 
Tunnelblick if you make any changes to 
your configuration files.
___________________

There is something else that could be happening: since the home folder is on a 
network drive, it could be that 
setting up the tunnel interferes with access to the home folder. I would have 
expected that not to show up 
until _after_ displaying entries in the log, but maybe not.

Good luck!

Original comment by jkbull...@gmail.com on 31 Jul 2009 at 2:11

• Changed state: Started

[GoogleCodeExporter]

Tunnelblick apparently *requires* that configuration files be owned by 
root:wheel
despite having them in a user's home directory. If you're mounting over NFS, 
you're
probably using the "root_squash" option for security. Root squashing forces uid 
0
(root) to be mapped to the guest account on the server. This prohibits 
accessing any
NFS mounted directories as root or changing the ownership of a file on an NFS 
mounted
directory to root.

Unless I'm missing something, the requirement that those files be root:wheel 
*cannot*
work with NFS mounted home directories using root_squash.

Original comment by Nox...@gmail.com on 15 Sep 2009 at 10:33

[GoogleCodeExporter]

Yes I understand about root_squash.

The questions is WHY does tunnelblick require this and can it be changed?

Original comment by dean.jo...@gmail.com on 15 Sep 2009 at 10:54

[GoogleCodeExporter]

From the FAQ at
http://code.google.com/p/tunnelblick/wiki/FAQ

"Why does Tunnelblick change the ownership of the configuration files to root?

This is a security issue. OpenVPN configuration files allow you to specify 
up/down scripts which will be 
executed with root privileges every time a VPN connection is started or 
stopped. If the configuration files were 
owned by the local user, anyone could execute arbitrary code as root by 
inserting an 'up' directive to the 
configuration file and pointing it to a (malicious) shell script. Therefore, on 
the first run, Tunnelblick changes 
the ownership of the configuration file to root, so it is protected against 
unnoticed and possibly malicious 
changes. Similarly, if new configuration files are added, Tunnelblick will ask 
for a computer administrator's 
password to change the ownership of the new file to root."

Original comment by jkbull...@gmail.com on 15 Sep 2009 at 11:07

[GoogleCodeExporter]

I've thought up a way around this problem, which I think will work: keep and 
use a "shadow copy" of config 
file(s) on the local volume in /Library/Tunnelblick/USER/, where USER is the 
short username of the currently 
logged in user. From the user's and administrator's perspective, this would 
behave almost identically to 
having the config file(s) on a local volume.

The main issue I see is that a copy of the config file is kept on the local 
drive; one might not want to do this 
on a non-trusted computer. But then again, if the computer isn't trusted, 
Tunnelblick won't help much -- 
keyloggers, etc. could do more damage than something that stole the config file.

I don't know enough about how network logins work and whether or not this is 
possible, but if two different 
users with the same username use the computer and they have different config 
files in their home folders, the 
local copy of the config file will be replaced each time they log in 
alternately, requiring the admin 
username/password. (But each one will still be secure from the other.)

The other issue is that we're putting stuff in /Library, which is non-standard. 
But I think Parallels does 
something vaguely similar to enable a single Windows disk image to be shared 
among all users on a 
computer.

Reactions?

Original comment by jkbull...@gmail.com on 18 Sep 2009 at 10:16

[GoogleCodeExporter]

FIxed (crossed fingers) in r188, by implementing "shadow copying" of the config 
file. This is done automatically 
if the config file is on a network volume. It is also done if the 
"useShadowConfigurationFiles" preference is set.

Original comment by jkbull...@gmail.com on 21 Sep 2009 at 11:15

• Changed state: Fixed