Upstream ships with tor.service in its "contrib" directory. Gentoo should use it instead of including a completely separate tor.service. Upstream's is better maintained and has some better security features (hardening) than the one Gentoo includes. Reproducible: Always
This issue is valid as of net-misc/tor-0.2.6.1_alpha
(In reply to candrews from comment #1) > This issue is valid as of net-misc/tor-0.2.6.1_alpha I'm okay with that. I don't use systemd and someone just contributed that versions, so I put it in there. I'll alert the systemd team just in case there is some reason I shouldn't that I don't know about. @Candrews, I assume you tested the upstream contrib version and it worked?
That's right, I'm using the upstream version (I didn't have to change it at all) and it's working great.
tor-0.2.5.10-r1.ebuild tor-0.2.6.1_alpha-r1.ebuild now use the upstream tor.service file. Please test and reopen if there's still a problem.
Created attachment 389598 [details] New tor.service file simply does not work.
In https://gitweb.torproject.org/tor.git/blob/HEAD:/contrib/dist/tor.service.in , the variable "@LOCALSTATEDIR@" is expanded to "/var/lib" but it should be expanded to "/var" which is the problem. Ex, this line: ReadWriteDirectories = @LOCALSTATEDIR@/lib/tor should become: ReadWriteDirectories = /var/lib/tor but currently actually becomes: ReadWriteDirectories = /var/lib/lib/tor I assume this issue is with the ebuild as other distros that use this (ex Fedora) haven't encountered this problem? As a workaround for others that encounter this bug, just create /etc/systemd/service/tor.service with these contents: --- [Unit] Description = Anonymizing overlay network for TCP After = syslog.target network.target nss-lookup.target [Service] Type = simple ExecStartPre = /usr/bin/tor -f /etc/tor/torrc --verify-config # A torrc that has "RunAsDaemon 1" won't work with the "simple" service type; # let's explicitly override it. ExecStart = /usr/bin/tor -f /etc/tor/torrc --RunAsDaemon 0 ExecReload = /bin/kill -HUP ${MAINPID} KillSignal = SIGINT TimeoutSec = 30 Restart = on-failure LimitNOFILE = 32768 # Hardening PrivateTmp = yes DeviceAllow = /dev/null rw DeviceAllow = /dev/urandom r InaccessibleDirectories = /home ReadOnlyDirectories = / ReadWriteDirectories = /var/lib/tor ReadWriteDirectories = /var/log/tor ReadWriteDirectories = /var/run/tor ReadWriteDirectories = /proc NoNewPrivileges = yes [Install] WantedBy = multi-user.target ---
(In reply to candrews from comment #6) > In > https://gitweb.torproject.org/tor.git/blob/HEAD:/contrib/dist/tor.service.in > , the variable "@LOCALSTATEDIR@" is expanded to "/var/lib" but it should be > expanded to "/var" which is the problem. Ex, this line: > ReadWriteDirectories = @LOCALSTATEDIR@/lib/tor > should become: > ReadWriteDirectories = /var/lib/tor > but currently actually becomes: > ReadWriteDirectories = /var/lib/lib/tor > > I assume this issue is with the ebuild as other distros that use this (ex > Fedora) haven't encountered this problem? There is nothing in the ebuild that would cause this. Can we find what's going on in the build system? > > As a workaround for others that encounter this bug, just create > /etc/systemd/service/tor.service with these contents: > --- > [Unit] > Description = Anonymizing overlay network for TCP > After = syslog.target network.target nss-lookup.target > > [Service] > Type = simple > ExecStartPre = /usr/bin/tor -f /etc/tor/torrc --verify-config > # A torrc that has "RunAsDaemon 1" won't work with the "simple" service type; > # let's explicitly override it. > ExecStart = /usr/bin/tor -f /etc/tor/torrc --RunAsDaemon 0 > ExecReload = /bin/kill -HUP ${MAINPID} > KillSignal = SIGINT > TimeoutSec = 30 > Restart = on-failure > LimitNOFILE = 32768 > > # Hardening > PrivateTmp = yes > DeviceAllow = /dev/null rw > DeviceAllow = /dev/urandom r > InaccessibleDirectories = /home > ReadOnlyDirectories = / > ReadWriteDirectories = /var/lib/tor > ReadWriteDirectories = /var/log/tor > ReadWriteDirectories = /var/run/tor > ReadWriteDirectories = /proc > NoNewPrivileges = yes > > [Install] > WantedBy = multi-user.target > --- Can people please test this (I menan really test this) befor I commit.
(In reply to Anthony Basile from comment #7) > (In reply to candrews from comment #6) > > In > > https://gitweb.torproject.org/tor.git/blob/HEAD:/contrib/dist/tor.service.in > > , the variable "@LOCALSTATEDIR@" is expanded to "/var/lib" but it should be > > expanded to "/var" which is the problem. Ex, this line: > > ReadWriteDirectories = @LOCALSTATEDIR@/lib/tor > > should become: > > ReadWriteDirectories = /var/lib/tor > > but currently actually becomes: > > ReadWriteDirectories = /var/lib/lib/tor > > > > I assume this issue is with the ebuild as other distros that use this (ex > > Fedora) haven't encountered this problem? > > There is nothing in the ebuild that would cause this. Can we find what's > going on in the build system? > > > > > As a workaround for others that encounter this bug, just create > > /etc/systemd/service/tor.service with these contents: > > --- > > [Unit] > > Description = Anonymizing overlay network for TCP > > After = syslog.target network.target nss-lookup.target > > > > [Service] > > Type = simple > > ExecStartPre = /usr/bin/tor -f /etc/tor/torrc --verify-config > > # A torrc that has "RunAsDaemon 1" won't work with the "simple" service type; > > # let's explicitly override it. > > ExecStart = /usr/bin/tor -f /etc/tor/torrc --RunAsDaemon 0 > > ExecReload = /bin/kill -HUP ${MAINPID} > > KillSignal = SIGINT > > TimeoutSec = 30 > > Restart = on-failure > > LimitNOFILE = 32768 > > > > # Hardening > > PrivateTmp = yes > > DeviceAllow = /dev/null rw > > DeviceAllow = /dev/urandom r > > InaccessibleDirectories = /home > > ReadOnlyDirectories = / > > ReadWriteDirectories = /var/lib/tor > > ReadWriteDirectories = /var/log/tor > > ReadWriteDirectories = /var/run/tor > > ReadWriteDirectories = /proc > > NoNewPrivileges = yes > > > > [Install] > > WantedBy = multi-user.target > > --- > > Can people please test this (I menan really test this) befor I commit. ping
(In reply to Anthony Basile from comment #8) tor.service from comment #6 does not work.
(In reply to Yuki N. from comment #9) > (In reply to Anthony Basile from comment #8) > tor.service from comment #6 does not work. Okay too much failing stuff here. Everytime I push this I force a recompile on people running tor ~arch, so I'm going to revert and leave things as is until there is consensus that a solution really works.
(In reply to Yuki N. from comment #9) > (In reply to Anthony Basile from comment #8) > tor.service from comment #6 does not work. I'm using that tor.service and I don't see any problems so I don't know what problem you're seeing. Can you please tell me what problem you're seeing so I can work on fixing it?
cc systemd people to advise here.
The systemd service file provided by upstream doesn't seem to be terribly lovely crafted, too... Given the fact that increased hardening for tor is sometimes desirable, we should provide an easy option to enable it. On the other hand the default configuration should just always work. Therefore, in an attempt to please all as much as possible, I'd suggest the following: (a) Only install a bare bones tor.serivce file that mimics /etc/init.d/tor (as we are currently doing). More or less the current serivce file with some minor modifications: [Unit] Description=The Onion Router [Service] Type=simple ExecStartPre=/usr/bin/tor --verify-config -f /etc/tor/torrc ExecStart=/usr/bin/tor --RunAsDaemon 0 -f /etc/tor/torrc ExecReload=/bin/kill -HUP $MAINPID KillSignal=SIGINT TimeoutStopSec=32 LimitNOFILE=30000 [Install] WantedBy=multi-user.target (Why was there a Group= statement??? The daemon drops privileges automatically to UID/GID tor/tor.) (b) Provide a drop-in. Upstream's hardening configuration is a bit suboptimal, this should do the same thing while avoiding any gentoo specific paths: # Uncomment the following lines to enable additional hardening options for # tor that are available with systemd (private tmp and minimal /dev, # inaccesible /home and /run/user, read only /usr and /etc): # PrivateTmp = yes # PrivateDevices = yes # ProtectHome = yes # ProtectSystem = full # NoNewPrivileges = yes This file could e.g. be named "${FILESDIR}"/tor/service.conf and installed via systemd_install_serviced "${FILESDIR}"/tor.service.conf that will drop it into /etc as /etc/systemd/system/tor.service.d/00gentoo.conf
The idea sounds nice but do is the need for the 'non-hardened' version common? Maybe we want at least some of those options on by default.
If we think there are problem with the tor.service, shouldn't we submit those problems, suggestions, and improvement upstream so that all distros benefit? Having tor.service upstream also reduces the maintenance burden in Gentoo. Finally, taking a step back, as far as I can tell, upstream's tor.service works if we just fix the "double /lib" problem described in comment #6. I suggest that we do 2 things: 1) Make Gentoo use upstream's tor.service (fixing the "double /lib" problem) 2) Submit improvements upstream
Well, no it doesn't. It has additional problems. ReadWriteDirectories = /var/lib/tor ReadWriteDirectories = /var/log/tor ReadWriteDirectories = /var/run/tor This will fail with a cryptic error message in case one of one those directories not being available, ProtectSystem=full is by far the better option. If we consider this, we currently have to patch the majority of the hardening options anyway, so providing our own service file makes sense in this case. With respect to upstream interaction I see little benefit to go into any length of dicussion about a systemd service file - we will have to consantly customize it for our needs anyway.
After a short discussion we came to the conclusion to just propose to update the service file to the following without installing anything else under /etc/systemd/*: [Unit] Description=The Onion Router [Service] Type=simple ExecStartPre=/usr/bin/tor --verify-config -f /etc/tor/torrc ExecStart=/usr/bin/tor --RunAsDaemon 0 -f /etc/tor/torrc ExecReload=/bin/kill -HUP $MAINPID KillSignal=SIGINT TimeoutStopSec=32 LimitNOFILE=30000 # Hardening options: PrivateTmp = yes PrivateDevices = yes ProtectHome = yes ProtectSystem = full NoNewPrivileges = yes [Install] WantedBy=multi-user.target I've tested this configuration - it works for me with the default configuration. The bundled upstream service file doesn't (due to the issues pointed out earlier). As user there is still the opportunity to override everything of this with a drop-in in /etc/systemd/system/tor.service.d
(In reply to Matthias Maier from comment #17) > After a short discussion we came to the conclusion to just propose to update > the service file to the following without installing anything else under > /etc/systemd/*: Agree. Unless the "hardening" breaks things there is no reason to make it optional. If the upstream file doesn't work as-is then let's use the best solution possible.
(In reply to candrews from comment #15) > If we think there are problem with the tor.service, shouldn't we submit > those problems, suggestions, and improvement upstream so that all distros > benefit? > Anyone can submit upstream. Open a bug at https://trac.torproject.org/projects/tor/report and reference this bug.
Reviewing the changes to tor.service... 1) Was the change from "TimeoutSec" to "TimeoutStopSec" intentional? It seems like "TimeoutSec" would be the right thing to do here. 2) "LimitNOFILE=32768" was changed to "LimitNOFILE=30000" - that seems like a weird change. 3) "Restart = on-failure" was removed - it seems like having that present is a good thing. 4) I suggest that: CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETUID CAP_SETGID be added as well. Also, I created a request with tor upstream to update the hardening configuration of their tor.service: https://trac.torproject.org/projects/tor/ticket/13805 I still really think that working with upstream and using what they provide whenever possible is preferable to maintain per distro modifications. If Gentoo, Fedora, SUSE, etc all work with upstream, they all benefit - and I don't really understand why Gentoo or any other distro would have to constantly customize it for their needs... it seems like the systemd service definition should be identical on all distros. Thanks again for working on this issue!
(In reply to candrews from comment #20) > I still really think that working with upstream and using what they provide > whenever possible is preferable to maintain per distro modifications. If > Gentoo, Fedora, SUSE, etc all work with upstream, they all benefit - and I > don't really understand why Gentoo or any other distro would have to > constantly customize it for their needs... it seems like the systemd service > definition should be identical on all distros. > I'm all about upstream maintaining this :) If there's a satifactory solution upstream, I'm sure it'll be out in the next 0.2.5 and 0.2.6.
(In reply to candrews from comment #20) > Reviewing the changes to tor.service... > > 1) Was the change from "TimeoutSec" to "TimeoutStopSec" intentional? It > seems like "TimeoutSec" would be the right thing to do here. Why override the timeout in the first place? Is tor known to start or stop long? > 2) "LimitNOFILE=32768" was changed to "LimitNOFILE=30000" - that seems like > a weird change. Do we actually need such a high limit? Does tor happen to open a lot of files? I think setting LimitNOFILE makes sense only if we either need to override supposedly-user-set limit with something much higher, or if we need to contain broken app (and in the latter case, it sounds a bad idea anyway). > 3) "Restart = on-failure" was removed - it seems like having that present is > a good thing. Is tor known tor exit randomly during runtime for non-important reasons? > Also, I created a request with tor upstream to update the hardening > configuration of their tor.service: > https://trac.torproject.org/projects/tor/ticket/13805 I would prefer if you waited for our review before submitting files upstream. One of the major issues with systemd is that people submit unit files upstream without consulting them well, and then distribution developers have a hard time convincing upstream that another change is necessary.
(In reply to Michał Górny from comment #22) > (In reply to candrews from comment #20) > > Reviewing the changes to tor.service... > > > > 1) Was the change from "TimeoutSec" to "TimeoutStopSec" intentional? It > > seems like "TimeoutSec" would be the right thing to do here. > > Why override the timeout in the first place? Is tor known to start or stop > long? TimeoutSec was introduced in https://trac.torproject.org/projects/tor/ticket/8368 , no reason was given. FWIW, I think having reasonable TimeoutSec values for service is generally a good practice. > > > 2) "LimitNOFILE=32768" was changed to "LimitNOFILE=30000" - that seems like > > a weird change. > > Do we actually need such a high limit? Does tor happen to open a lot of > files? I think setting LimitNOFILE makes sense only if we either need to > override supposedly-user-set limit with something much higher, or if we need > to contain broken app (and in the latter case, it sounds a bad idea anyway). Having such a high LimitNOFILE value is necessary for fast relays (which may be a common use case). See https://trac.torproject.org/projects/tor/ticket/8368#comment:4 > > > 3) "Restart = on-failure" was removed - it seems like having that present is > > a good thing. > > Is tor known tor exit randomly during runtime for non-important reasons? I would be surprised if that was the case. :-) It's in the upstream file which was constructed by a Fedora developer and Tor, so is there a reason for Gentoo be different? > > > Also, I created a request with tor upstream to update the hardening > > configuration of their tor.service: > > https://trac.torproject.org/projects/tor/ticket/13805 > > I would prefer if you waited for our review before submitting files > upstream. One of the major issues with systemd is that people submit unit > files upstream without consulting them well, and then distribution > developers have a hard time convincing upstream that another change is > necessary. I thought the review the complete ("...we came to the conclusion...") and there was a suggestion in another comment that anyone can create bugs upstream. I'm just trying to help :) Thanks again!
(In reply to candrews from comment #23) > (In reply to Michał Górny from comment #22) > > (In reply to candrews from comment #20) > > > Reviewing the changes to tor.service... > > > > > > 1) Was the change from "TimeoutSec" to "TimeoutStopSec" intentional? It > > > seems like "TimeoutSec" would be the right thing to do here. > > > > Why override the timeout in the first place? Is tor known to start or stop > > long? > > TimeoutSec was introduced in > https://trac.torproject.org/projects/tor/ticket/8368 , no reason was given. > FWIW, I think having reasonable TimeoutSec values for service is generally a > good practice. systemd has a default timeout, and user can change it in system.conf. Service setting overrides the user-set global timeout, and it should do that only when there's a good reason to -- for example, when a specific service takes real long to shutdown or start. > > > 3) "Restart = on-failure" was removed - it seems like having that present is > > > a good thing. > > > > Is tor known tor exit randomly during runtime for non-important reasons? > > I would be surprised if that was the case. :-) > It's in the upstream file which was constructed by a Fedora developer and > Tor, so is there a reason for Gentoo be different? I think it'd be a good idea to explain to upstream that Restart here is unnecessary and confusing. > > > Also, I created a request with tor upstream to update the hardening > > > configuration of their tor.service: > > > https://trac.torproject.org/projects/tor/ticket/13805 > > > > I would prefer if you waited for our review before submitting files > > upstream. One of the major issues with systemd is that people submit unit > > files upstream without consulting them well, and then distribution > > developers have a hard time convincing upstream that another change is > > necessary. > > I thought the review the complete ("...we came to the conclusion...") and > there was a suggestion in another comment that anyone can create bugs > upstream. I'm just trying to help :) No problem.
(In reply to Michał Górny from comment #24) > > I think it'd be a good idea to explain to upstream that Restart here is > unnecessary and confusing. > The first thing I do is add Restart=always as a drop-in for just about every service I run. It is really annoying to have to do this. Yes, tor shouldn't crash. However, if it did, why wouldn't you want to restart it? Systemd will throttle things if they get out of hand.
(In reply to Richard Freeman from comment #25) > (In reply to Michał Górny from comment #24) > > > > I think it'd be a good idea to explain to upstream that Restart here is > > unnecessary and confusing. > > > > The first thing I do is add Restart=always as a drop-in for just about every > service I run. It is really annoying to have to do this. > > Yes, tor shouldn't crash. However, if it did, why wouldn't you want to > restart it? Systemd will throttle things if they get out of hand. Throttling is just one of the problems with autorestart. However, autorestarting services may have much more consequences than this, and should be used sparingly. Not sure if that applies to tor but more generally it can cause: (additional) data damage, service overloads, log spamming to the point of filling the whole filesystem (think of coredumps in journal!).
*tor-0.2.6.1_alpha-r3 (21 Nov 2014) *tor-0.2.5.10-r3 (21 Nov 2014) 21 Nov 2014; Matthias Maier <tamiko@gentoo.org> +tor-0.2.5.10-r3.ebuild, +tor-0.2.6.1_alpha-r3.ebuild, -tor-0.2.5.10-r2.ebuild, -tor-0.2.6.1_alpha-r2.ebuild, files/tor.service: set additional hardening options for tor.service file, wrt bug #529212 I have commited the following service file: [Unit] Description=The Onion Router [Service] ExecStartPre=/usr/bin/tor --verify-config -f /etc/tor/torrc ExecStart=/usr/bin/tor --RunAsDaemon 0 -f /etc/tor/torrc ExecReload=/bin/kill -HUP $MAINPID KillSignal=SIGINT TimeoutStopSec=32 LimitNOFILE=30000 # Hardening options: CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE PrivateTmp = yes PrivateDevices = yes ProtectHome = yes ProtectSystem = full NoNewPrivileges = yes [Install] WantedBy=multi-user.target @candrews: - the limit of 30000 for LimitNOFILE was chosen to match the corresponding configuration in /etc/conf.d/tor. If upstream likes to use binary powers, no problem. - The timeout of 32 seconds was chosen to ensure that the daemon receives a SIGNINT and after that has 30 seconds to gracefully close connections. After that a SIGTERM is sent with another 32 seconds. Finally a SIGKILL. This is more than the usual systemd default - but ensures that extremely short user overrides in /etc/systemd/system.conf are overruled. - I have added the capabilities bounding set you proposed. This is a good addition. Can you please update the upstream bug accordingly? Specifically it might be good to post the full service file to avoid confusion. @ blueness: Thanks for the trust to be allowed to commit to your package :-]
* This is more restrictive than
Okay thanks for your help! This is in upstreams hands right now and we have a good temporary fix until upstream pushes down their fix. You can reopen this bug (or open another) when you want to switch out our unit file for upstream's.
Upstream just finished their work on this issue at https://trac.torproject.org/projects/tor/ticket/13805 They also added watchdog support: https://trac.torproject.org/projects/tor/ticket/11016 (No additional work needed by distros, which is pretty cool) So it would be really neat to use upstream's service definitions. For your convenience, here's the current state of upstream's tor.service: https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in I'm still concerned that @LOCALSTATEDIR@ won't be properly expanded in Gentoo. In the last attempt, @LOCALSTATEDIR@ expanded to "/var/lib" but it have expanded to "/var" - I'm unclear as to how to fix that, and I'm skeptical that it's a problem in upstream tor.
the CapabilityBoundingSet line prevents the ControlSocket functionality from working: [notice] Opening Control listener on /var/run/tor/control [warn] Could not unlink /var/run/tor/control: Permission denied
(In reply to poncho from comment #31) > the CapabilityBoundingSet line prevents the ControlSocket functionality from > working: > > [notice] Opening Control listener on /var/run/tor/control > [warn] Could not unlink /var/run/tor/control: Permission denied @systemd team. Let me know what you think here and I'll take care of it. I don't know what these unit files should have in them. Or is this a bug for upstream?
Reopen when someone from the systemd team has something.
Reopening so that we can track this. The bug exists whether the maintainer cares to personally work on it or not. He isn't required to, of course, as with any bug. It is a bit hard to track systemd units that need work when the bugs referencing them are closed.
(In reply to Richard Freeman from comment #34) > Reopening so that we can track this. > > The bug exists whether the maintainer cares to personally work on it or not. > He isn't required to, of course, as with any bug. It is a bit hard to track > systemd units that need work when the bugs referencing them are closed. I don't have the ability to work on this but I'm happy to add anything systemd team has for me. I'll reassign.
(In reply to Anthony Basile from comment #35) > I don't have the ability to work on this but I'm happy to add anything > systemd team has for me. I'll reassign. No objection, and this isn't the place for the discussion, but ownership of stuff like this is one of those things that is likely to become more of an issue in the future. When it reaches a point where packages start having systemd units but not init.d scripts, do we want to start assigning bugs to the openrc team?
(In reply to Richard Freeman from comment #36) > > When it reaches a point where packages start having systemd units but not > init.d scripts, do we want to start assigning bugs to the openrc team? Decide ad hoc. I can write init scripts for openrc with confidence, so if the wheels were turned, I would just take care of it myself. I can kinda sorta hack something ups for systemd but I would not have confidence that I haven't made a mess. So I'll reassign so systemd people to track this. BTW, i'm on the systemd list so I'm not out of the loop.
0.2.6.3-alpha has been released: https://gitweb.torproject.org/tor.git/
I just pushed out 0.2.6.3 with upstreams unit file. Can someone test and see if this is working? yellow tor # cat /var/tmp/portage/net-misc/tor-0.2.6.3_alpha/image/usr/lib/systemd/system/tor.service [Unit] Description=The Onion Router [Service] ExecStartPre=/usr/bin/tor --verify-config -f /etc/tor/torrc ExecStart=/usr/bin/tor --RunAsDaemon 0 -f /etc/tor/torrc ExecReload=/bin/kill -HUP $MAINPID KillSignal=SIGINT TimeoutStopSec=32 LimitNOFILE=30000 # Hardening options: CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE PrivateTmp = yes PrivateDevices = yes ProtectHome = yes ProtectSystem = full NoNewPrivileges = yes [Install] WantedBy=multi-user.target
Created attachment 398356 [details] 0.2.6.3-alpha Yep, version 0.2.6.3-alpha works fine.
(In reply to Yuki N. from comment #40) > Created attachment 398356 [details] > 0.2.6.3-alpha > > Yep, version 0.2.6.3-alpha works fine. Okay we'll wait a few days for more testing and then I'll *finally* close this bug :)
(In reply to Anthony Basile from comment #39) > I just pushed out 0.2.6.3 with upstreams unit file. Can someone test and > see if this is working? (In reply to poncho from comment #31) > the CapabilityBoundingSet line prevents the ControlSocket functionality from > working: > > [notice] Opening Control listener on /var/run/tor/control > [warn] Could not unlink /var/run/tor/control: Permission denied Unlinking the control socket still doesn't work. Since the ControlSocket entry is not part of the default torrc, it's maybe not worth bothering though.
This are the config changes I use to get a ControlSocket in /var/run/tor/ working. systemd-delta --- /usr/lib/tmpfiles.d/tor.conf 2015-03-08 09:53:41.000000000 +0100 +++ /etc/tmpfiles.d/tor.conf 2015-02-20 14:26:04.359442929 +0100 @@ -1 +1 @@ -d /var/run/tor 0775 tor tor - - +d /var/run/tor 0750 tor tor - - --- /usr/lib/systemd/system/tor.service 2015-03-08 09:53:41.000000000 +0100 +++ /etc/systemd/system/tor.service 2015-03-08 10:36:34.142866818 +0100 @@ -10,7 +10,7 @@ LimitNOFILE=30000 # Hardening options: -CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE +CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE CAP_CHOWN CAP_FOWNER PrivateTmp = yes PrivateDevices = yes ProtectHome = yes cat /etc/tor/torrc User tor PIDFile /var/run/tor/tor.pid Log notice syslog DataDirectory /var/lib/tor/data SocksPort 127.0.0.1:9050 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1
(In reply to poncho from comment #42) > (In reply to Anthony Basile from comment #39) > > I just pushed out 0.2.6.3 with upstreams unit file. Can someone test and > > see if this is working? > Can you try to get a bug going upstream tor: https://trac.torproject.org/projects/tor I'd like to get this right, but I'm not familiar with unit files and don't run systemd.
(In reply to Anthony Basile from comment #44) > Can you try to get a bug going upstream tor: > https://trac.torproject.org/projects/tor https://trac.torproject.org/projects/tor/ticket/15195
net-misc/tor-0.2.7.3_rc systemd cannot reload tor: # systemctl reload tor Job for tor.service failed. See "systemctl status tor.service" and "journalctl -xe" for details. systemd[1]: Reloading The Onion Router. systemd[1]: tor.service: control process exited, code=exited status=1 systemd[1]: Reload failed for The Onion Router. I am not sure that this should be posted here (is this a different issue?)
Created attachment 454980 [details] tor service file Hi, If anyone is interested/communicates with upstream, I created the following tor.service, which mostly works. the Control Socket works, the only thing I know that doesn't work is listening on ports < 1024. For some reason CAP_NET_BIND_SERVICE isn't enough...
(In reply to Martin from comment #47) > Created attachment 454980 [details] > tor service file > > Hi, > > If anyone is interested/communicates with upstream, I created the following > tor.service, which mostly works. > the Control Socket works, the only thing I know that doesn't work is > listening on ports < 1024. For some reason CAP_NET_BIND_SERVICE isn't > enough... Tor bugs are reported here: https://trac.torproject.org/projects/tor I'm not prepared to push this bug through because I don't use systemd but would encourage anyone who is interested to do so.
Ok, reported upstream. https://trac.torproject.org/projects/tor/ticket/20930
Here's a PR for using upstream's systemd unit: https://github.com/gentoo/gentoo/pull/3322 Let's try to get to any further systemd unit improvements made upstream.
