Hi devs,
User here. teor send me over from IRC. It's regarding to this trac-ticket https://trac.torproject.org/projects/tor/ticket/16518 After upgrading from 0.2.5.12 (git-3731dd5c3071dcba) to 0.2.6.9 (git-145b2587d1269af4) an error occured. I'm on Debian Jessie (stable) on an AMD Athlon 64 X2. Tor won't start and these are the last lines in log: [warn] Couldn't open "/media/cRAID/Tor/lock" for locking: Read-only file system [err] set_options(): Bug: Acting on config options left us in a broken state. Dying.
Here's the full log: http://www.file-upload.net/download-10748122/aexllog.gz.html Here's also a pastebin of some shell commands I did for the IRC chat: http://lpaste.net/136099
debug just also contains: [debug] tor_disable_debugger_attach(): Attemping to disable debugger attachment to Tor for unprivileged users. [debug] tor_disable_debugger_attach(): Debugger attachment disabled for unprivileged users. [info] tor_lockfile_lock(): Locking "/media/cRAID/Tor/lock"
teor thinks that I "could be experiencing an issue with the tor sandbox and not getting the right paths or, tor is running with insufficient permissions"
teor's help and mindfulness was much appreciated. It lasted about 7 days for me to realize that Tor wasn't running. I'm now operating 0.2.5.12 successfully, hoping that it's still secure.
Kindest regards
Sounds like access control gone wrong. An older version works but a newer version fails. Permissions on the filesystem look fine from mount output. So do you use access control, apparmor, selinux, grsecurity, fsprotect, bilibop, etc? In particular the tor package which is mentioned in your ticket includes an apparmor profile and suggests apparmor-utils.
Also try checking your system logs --leeroy
On 8 Jul 2015, at 08:06 , l.m ter.one.leeboi@hush.com wrote:
Sounds like access control gone wrong. An older version works but a newer version fails. Permissions on the filesystem look fine from mount output. So do you use access control, apparmor, selinux, grsecurity, fsprotect, bilibop, etc? In particular the tor package which is mentioned in your ticket includes an apparmor profile and suggests apparmor-utils.
Also try checking your system logs
arma asked similar questions on the ticket itself:
Comment (by arma):
A) Maybe it is Tor's sandbox code, misunderstanding where your datadirectory is?
B) Maybe it is some fancy selinux thing or the like?
Which of those does Wheezy have?
Tim Wilson-Brown (teor)
teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
On 8 Jul 2015, at 08:06 , l.m <ter.one.leeboi at hush.com> wrote:
Sounds like access control gone wrong. An older version works but a newer version fails. Permissions on the filesystem look fine from mount output. So do you use access control, apparmor, selinux, grsecurity, fsprotect, bilibop, etc? In particular the tor package which is mentioned in your ticket includes an apparmor profile and suggests apparmor-utils.
Also try checking your system logs
arma asked similar questions on the ticket itself:
Comment (by arma):
A) Maybe it is Tor's sandbox code, misunderstanding where your datadirectory is?
B) Maybe it is some fancy selinux thing or the like?
Which of those does Wheezy have?
Tim Wilson-Brown (teor)
teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
Sounds like access control gone wrong. An older version works but a newer version fails. Permissions on the filesystem look fine from mount output. So do you use access control, apparmor, selinux, grsecurity, fsprotect, bilibop, etc? In particular the tor package which is mentioned in your ticket includes an apparmor profile and suggests apparmor-utils.
Also try checking your system logs --leeroy
Even for read-only filesystem, tor will attempt to fix folder permission using chmod. I find it unusual that I don't see this in your logs.
--leeroy
aexlfowley@web.de wrote (08 Jul 2015 17:57:24 GMT) :
(Both packages for 0.2.5.12 and 0.2.6.9 contain an apparmor profile. Only change and new line is /usr/bin/obfs4proxy PUx, in /etc/apparmor.d/abstracions/tor)
FTR, the systemd unit file in Debian sid's 0.2.6.9-1 doesn't enable the AppArmor profile (yet), so I doubt AppArmor has anything to do with this problem (aa-status will tell you).
However, it has:
PrivateTmp=yes PrivateDevices=yes ProtectHome=yes ProtectSystem=full ReadOnlyDirectories=/ ReadWriteDirectories=-/var/lib/tor ReadWriteDirectories=-/var/log/tor ReadWriteDirectories=-/var/run
... which explains why /media/cRAID/Tor/lock isn't writable.
So you'll want to add what is called a "drop-in override file" in systemd's terminology (that can be created e.g. with `systemctl edit'), that adds a ReadWriteDirectories= directive pointing to the directory you want.
Cheers, -- intrigeri
On Tue, 07 Jul 2015, aexlfowley@web.de wrote:
After upgrading from 0.2.5.12 (git-3731dd5c3071dcba) to 0.2.6.9 (git-145b2587d1269af4) an error occured. I'm on Debian Jessie (stable) on an AMD Athlon 64 X2. Tor won't start and these are the last lines in log: [warn] Couldn't open "/media/cRAID/Tor/lock" for locking: Read-only file system
teor thinks that I "could be experiencing an issue with the tor sandbox and not getting the right paths or, tor is running with insufficient permissions"
I'd assume that's the protection settings enabled in Tor's service file.
See /lib/systemd/system/tor.service and the systemd.exec(5) manpage. You can override these by making your own /etc/systemd/system/tor.service file.
Cheers,
On Tue, 07 Jul 2015, aexlfowley at web.de wrote:
After upgrading from 0.2.5.12 (git-3731dd5c3071dcba) to 0.2.6.9 (git-145b2587d1269af4) an error occured. I'm on Debian Jessie (stable) on an AMD Athlon 64 X2. Tor won't start and these are the last lines in log: [warn] Couldn't open "/media/cRAID/Tor/lock" for locking: Read-only file system
teor thinks that I "could be experiencing an issue with the tor sandbox and not getting the right paths or, tor is running with insufficient permissions"
I'd assume that's the protection settings enabled in Tor's service file.
See /lib/systemd/system/tor.service and the systemd.exec(5) manpage. You can override these by making your own /etc/systemd/system/tor.service file.
Cheers,
| .''`. ** Debian ** Peter Palfrader | : :' : The universalhttp://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/
aexlfowley at web.de wrote (08 Jul 2015 17:57:24 GMT) :
(Both packages for 0.2.5.12 and 0.2.6.9 contain an apparmor profile. Only change and new line is /usr/bin/obfs4proxy PUx, in /etc/apparmor.d/abstracions/tor)
FTR, the systemd unit file in Debian sid's 0.2.6.9-1 doesn't enable the AppArmor profile (yet), so I doubt AppArmor has anything to do with this problem (aa-status will tell you).
However, it has:
PrivateTmp=yes PrivateDevices=yes ProtectHome=yes ProtectSystem=full ReadOnlyDirectories=/ ReadWriteDirectories=-/var/lib/tor ReadWriteDirectories=-/var/log/tor ReadWriteDirectories=-/var/run
... which explains why /media/cRAID/Tor/lock isn't writable.
So you'll want to add what is called a "drop-in override file" in systemd's terminology (that can be created e.g. with `systemctl edit'), that adds a ReadWriteDirectories= directive pointing to the directory you want.
Cheers,
intrigeri
Correct. I edited /lib/systemd/system/tor.service and added ReadWriteDirectories=-/media/cRAID/Tor and now 0.2.6.9 is running. I'm not entirely sure how to create my own /etc/systemd/system/tor.service so I leave it at that. (Trying out 'systemctl edit' I get "Unknown operation 'edit'." BTW.)
Thank you all!
On 07/09/2015 03:24 PM, aexlfowley@web.de wrote:
Correct. I edited /lib/systemd/system/tor.service and added ReadWriteDirectories=-/media/cRAID/Tor and now 0.2.6.9 is running. I'm not entirely sure how to create my own /etc/systemd/system/tor.service so I leave it at that. (Trying out 'systemctl edit' I get "Unknown operation 'edit'." BTW.)
Just copy the /lib/systemd/system/tor.service file to /etc/systemd/system and edit it there -- it will take precedence over the one in /lib . You don't want to edit the one in /lib directly, since it is meant to be for distribution files that can/should be replaced on upgrades.
Moritz Bartl wrote (09 Jul 2015 14:21:26 GMT) :
Just copy the /lib/systemd/system/tor.service file to /etc/systemd/system and edit it there -- it will take precedence over the one in /lib . You don't want to edit the one in /lib directly, since it is meant to be for distribution files that can/should be replaced on upgrades.
Right. And even better: using drop-in override files would avoid having to maintain a local forked copy of the unit file. Look for ".conf" in systemd.unit(5).
Cheers, -- intrigeri
On Thu, Jul 9, 2015 at 11:44 AM, intrigeri intrigeri@boum.org wrote:
Moritz Bartl wrote (09 Jul 2015 14:21:26 GMT) :
Just copy the /lib/systemd/system/tor.service file to /etc/systemd/system and edit it there -- it will take precedence over the one in /lib . You don't want to edit the one in /lib directly, since it is meant to be for distribution files that can/should be replaced on upgrades.
Right. And even better: using drop-in override files would avoid having to maintain a local forked copy of the unit file. Look for ".conf" in systemd.unit(5).
If this one turned out to be NotABug, could somebody close the ticket mentioned in the subject line?
On 07/09/2015 03:24 PM, aexlfowley at web.de wrote:
Correct. I edited /lib/systemd/system/tor.service and added ReadWriteDirectories=-/media/cRAID/Tor and now 0.2.6.9 is running. I'm not entirely sure how to create my own /etc/systemd/system/tor.service so I leave it at that. (Trying out 'systemctl edit' I get "Unknown operation 'edit'." BTW.)
Just copy the /lib/systemd/system/tor.service file to /etc/systemd/system and edit it there -- it will take precedence over the one in /lib . You don't want to edit the one in /lib directly, since it is meant to be for distribution files that can/should be replaced on upgrades.
Moritz Bartl wrote (09 Jul 2015 14:21:26 GMT) :
Just copy the /lib/systemd/system/tor.service file to /etc/systemd/system and edit it there -- it will take precedence over the one in /lib . You don't want to edit the one in /lib directly, since it is meant to be for distribution files that can/should be replaced on upgrades.
Right. And even better: using drop-in override files would avoid having to maintain a local forked copy of the unit file. Look for ".conf" in systemd.unit(5).
Cheers,
intrigeri
Okay, so I created /etc/systemd/system/tor.service.d/directory.conf containing [Service] ReadWriteDirectories=/media/cRAID/Tor
Thanks again. And sorry for the noise.
-
aexlfowley＠web.de -
intrigeri -
l.m -
Moritz Bartl -
Nick Mathewson -
Peter Palfrader -
teor