Your message dated Fri, 7 Jul 2017 07:23:24 +0000 with message-id <20170707072324.33cbc3gr3thyw...@sarek.noreply.org> and subject line Re: Bug#846275: provide a directory for hidden service socket files has caused the Debian Bug report #846275, regarding provide a directory for hidden service socket files to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 846275: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846275 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: tor Version: 0.2.8.9-1 Severity: normal When running a tor hidden service, it's desirable to run it as a different user than debian-tor, and it's safer to use a unix socket than it is to run the hidden service on a localhost port. However, when a unix socket file is used for communication between tor and the hidden service, there is no good location to put it in. I suggest providing such a location. It seems that /etc/apparmor.d/system_tor is used by default on systemd systems -- it appears to be limiting here what tor can read, although I don't have apparmor packages installed. In that file, tor is locked down to only be able to access /var/lib/tor/, /var/run/tor/, and /etc/tor/ /var/lib/tor is only readable by debian-tor, so for the hidden service socket to be located somewhere in there, the hidden service would have to be run as debian-tor (user or group). /var/run/tor is world readable, so it would be possible to make a subdirectory, say /var/run/tor/hidden_service/, allow the hidden service user to write to the subdirectory so it can bind the socket, and tor would be able to use it. But, /var/run does not persist across reboots, so this subdirectory would need to be set up on each boot by root before the hidden service starts up. /etc/tor is the only other option. Indeed, /etc/tor/hidden_service/ can be set up to be writable by the hidden service user, it can put its socket there, and tor can read it. But putting a socket in /etc/ is a FHS violation. I am using tor hidden services for P2P communication between git-annex repositories. The user runs a command as root once to set up the hidden service for their repository. So my current choices to integrate this with Debian's tor package are: * Violate the FHS by putting a non-config file in /etc/tor/ * Modify the apparmor config shipped with tor to let it read the socket in some other location. Seems this would require restarting the tor daemon amoung other complications. * Add an init script that sets up subdirectories under /var/run/tor with appropriate owners on boot. Complicated. So, the configuration of this package is encouraging me to violate the FHS. It seems like the most robust and simplest way. I suggest that the Debian tor package include a world-readable directory, which tor is allowed to access by its apparmor config and any other things used to lock it down. Subdirectories can then be added as needed to contain hidden service unix sockets, etc. (Another use case for such a world-readable directory could be onionshare. It currently uses a HiddenServiceDir in /tmp/onionshare/, so that it can read the onion address from it, which it could not if it used /var/lib/tor. /etc/apparmor.d/torbrowser.Tor.tor has a special case for that onionshare directory. This is why the onionshare package depends on torbrowser-launcher; see #762890.) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tor depends on: ii adduser 3.115 ii init-system-helpers 1.46 ii libc6 2.24-5 ii libevent-2.0-5 2.0.21-stable-2.1 ii libseccomp2 2.3.1-2 ii libssl1.0.2 1.0.2j-4 ii libsystemd0 232-3 ii lsb-base 9.20161101 ii zlib1g 1:1.2.8.dfsg-2+b3 Versions of packages tor recommends: ii logrotate 3.8.7-2 ii tor-geoipdb 0.2.8.9-1 ii torsocks 2.2.0-1 Versions of packages tor suggests: pn apparmor-utils <none> pn mixmaster <none> pn obfs4proxy <none> pn obfsproxy <none> ii socat 1.7.3.1-1 pn tor-arm <none> ii torbrowser-launcher 0.2.6-2 -- Configuration Files: /etc/tor/torrc changed [not included] -- no debconf information -- see shy josignature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---On Wed, 21 Dec 2016, Joey Hess wrote: > Peter Palfrader wrote: > > Yes, see README.Debian in the most recent upload - > > https://gitweb.torproject.org/debian/tor.git/tree/debian/README.Debian > > > > Please let me know if this is what you had in mind. I'd appreciate any > > suggestions (or patches) for improvement :) > > Looks very good. Ok then. Closing this ticket. Thanks, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `- https://www.debian.org/
--- End Message ---