Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12
aexlfow...@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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.torproject.org/pipermail/tor-dev/attachments/20150708/eaf53671/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: Message signed with OpenPGP using GPGMail URL: http://lists.torproject.org/pipermail/tor-dev/attachments/20150708/eaf53671/attachment-0001.sig How do I check that sandbox thing? BTW I'm only running a bridge relay. I don't use TBB or whatever. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.torproject.org/pipermail/tor-dev/attachments/20150707/93389646/attachment.html ACL [1] is part of Debian. I presume that it's this way many years now ... I've updated the pastebin [2] with getfacl outputs. 0.2.5.12 still running. I don't have any of that other stuff installed. (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) My system logs don't contain anything I haven't released (I checked dmesg, /var/log/messages, syslog, kern.log). 1: https://wiki.debian.org/Permissions#Access_Control_Lists_in_Linux 2: http://lpaste.net/136099 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12
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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor#16518: Read-Only Filesystem Error opening tor lockfile in 0.2.6.9 but not 0.2.5.12
On Tue, 07 Jul 2015, aexlfow...@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 universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] CollecTor data: mapping bridge-network-status to bridge-server-descriptor to bridge-extra-info
I'm trying to use CollecTor data to find out how much bandwidth is offered by different pluggable transports over time. I.e., I want to be able to say something like, On July 1, bridges with obfs3 offered X MB/s, bridges with obfs4 offered Y MB/s, etc. To do this, I'm mapping through three types of CollecTor documents: bridge-network-status (where the bandwidth is and which links to router digests) bridge-server-descriptor (which links to extra-info digests) bridge-extra-info (where the transports are) I'm having trouble because sometimes, a router digest listed in a bridge-network-status document is not found in the same tarball. https://collector.torproject.org/archive/bridge-descriptors/bridge-descriptors-2015-07.tar.xz Here is an example of what I'm doing, using the above tarball. bridge-descriptors-2015-07/statuses/04/20150704-000350-4A0CCD2DDC7995083D73F5D667100C8A5831F16D This is a bridge-network-status document. One of its entries is: r starman qgM+62FgGytzEtibYqqiPcPtijQ mdOOBxVOTpw8loBezhSDZxLIcXs 2015-07-03 21:39:31 10.174.163.60 9002 0 s Fast Guard Running Stable Valid w Bandwidth=2646 p reject 1-65535 The second base64-encoded string is the router digest. base64decode(mdOOBxVOTpw8loBezhSDZxLIcXs) = 99D38E07154E4E9C3C96805ECE14836712C8717B bridge-descriptors-2015-07/server-descriptors/9/9/99d38e07154e4e9c3c96805ece14836712c8717b Now we go looking for a bridge-server-descriptor with router digest 99D38E07154E4E9C3C96805ECE14836712C8717B, which is in the above file. It has a line: extra-info-digest D69106C8BAF5C0044F7331F24DF77E85BBF84027 bridge-descriptors-2015-07/extra-infos/d/6/d69106c8baf5c0044f7331f24df77e85bbf84027 Now we find a bridge-extra-info with digest D69106C8BAF5C0044F7331F24DF77E85BBF84027 in the above file. It tells us what transports the bridge supports (there are two, one for IPv4 and one for IPv6): transport meek transport meek Here's an example of where it goes wrong. bridge-descriptors-2015-07/statuses/01/20150701-060138-4A0CCD2DDC7995083D73F5D667100C8A5831F16D r Unnamed ABk0wg4j6BLCdZKleVtmNrfzJGI eGIOW1mGM/Dbw+t5bXnR8jdnsoY 2015-07-01 05:56:14 10.123.124.91 443 0 s Fast Running Stable Valid w Bandwidth=156 p reject 1-65535 We are looking for router digest 78620E5B598633F0DBC3EB796D79D1F23767B286: base64decode(eGIOW1mGM/Dbw+t5bXnR8jdnsoY) = 78620E5B598633F0DBC3EB796D79D1F23767B286 But there is no file bridge-descriptors-2015-07/server-descriptors/7/8/78620e5b598633f0dbc3eb796d79d1f23767b286. However, I did find it in the previous month's tarball, https://collector.torproject.org/archive/bridge-descriptors/bridge-descriptors-2015-06.tar.xz bridge-descriptors-2015-06/server-descriptors/8/3/835a43ff89db9c1be8ddf7536d759875878620e7 It seems rare that the bridge-server-descriptor is missing. In the 2015-07 tarball, it happened for 5891/477496 relays (1.2%). An additional 4/477496 (0.0%) had a bridge-server-descriptor but were missing bridge-extra-info. How do you handle cases like this? I had a browse through the Onionoo source code, but did not quickly understand it. Should I just always include the month preceding the earliest month I want to process? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] CollecTor data: mapping bridge-network-status to bridge-server-descriptor to bridge-extra-info
On Wed, Jul 08, 2015 at 07:45:04PM -0700, David Fifield wrote: I'm trying to use CollecTor data to find out how much bandwidth is offered by different pluggable transports over time. I.e., I want to be able to say something like, On July 1, bridges with obfs3 offered X MB/s, bridges with obfs4 offered Y MB/s, etc. Great! I'm having trouble because sometimes, a router digest listed in a bridge-network-status document is not found in the same tarball. [snip] Here's an example of where it goes wrong. bridge-descriptors-2015-07/statuses/01/20150701-060138-4A0CCD2DDC7995083D73F5D667100C8A5831F16D Yeah, I'm not surprised it goes wrong, since the descriptor from 0701-06:01 was likely published in the previous month. However, I did find it in the previous month's tarball, Yep. It seems rare that the bridge-server-descriptor is missing. In the 2015-07 tarball, it happened for 5891/477496 relays (1.2%). [snip] How do you handle cases like this? I had a browse through the Onionoo source code, but did not quickly understand it. Should I just always include the month preceding the earliest month I want to process? How many of the 5891 cases does that resolve? --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
