GoogleCodeExporter
commented
9 years ago [deleted comment]Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago [deleted comment]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
commented
9 years ago 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
commented
9 years ago Fixed in trunk as r81.Original comment by jkbull...@gmail.com on 20 May 2009 at 4:01
GoogleCodeExporter
commented
9 years ago 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
commented
9 years ago Trunk r92 now has second try at fixing this. Original comment by jkbull...@gmail.com on 4 Jun 2009 at 5:04
GoogleCodeExporter
commented
9 years ago 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
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
Original issue reported on code.google.com by
dean.jo...@gmail.comon 19 Nov 2008 at 10:25