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 jo
signature.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 ---
