Bug#846275: Info received (Bug#846275: provide a directory for hidden service socket files)
I think I've figured out underlying problem that caused me to get confused about whether tor was able to access the sockets. Dec 21 13:50:16.000 [debug] rend_client_refetch_v2_renddesc(): Fetching v2 rendezvous descriptor for service [scrubbed] Dec 21 13:50:16.000 [info] pick_hsdir(): Could not pick one of the responsible hidden service directories, because we requested them all recently without success. Dec 21 13:50:16.000 [info] pick_hsdir(): Could not pick one of the responsible hidden service directories, because we requested them all recently without success. Dec 21 13:50:16.000 [info] fetch_v2_desc_by_addr(): Could not pick one of the responsible hidden service directories to fetch descriptors, because we already tried them all unsuccessfully. https://trac.torproject.org/projects/tor/ticket/16501 https://trac.torproject.org/projects/tor/ticket/15937 While testing my peer-to-peer use of tor hidden services, I was running multiple hidden services on one development machine. Each peer would try to contact the other's hidden service. As seen in the bug reports above, multiple SOCKS connections to a hidden service could cause some of the requests to fail. Those bugs reports seem to have been dealt with, but I am still experiencing what seems to be a similar problem. I've filed a new bug report on tor about that: https://trac.torproject.org/projects/tor/ticket/21056 -- see shy jo signature.asc Description: PGP signature
Bug#846275: provide a directory for hidden service socket files
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. -- see shy jo signature.asc Description: PGP signature
Bug#846275: provide a directory for hidden service socket files
On Tue, 20 Dec 2016, Joey Hess wrote: > Peter Palfrader wrote: > > On Sun, 18 Dec 2016, Joey Hess wrote: > > > > > But, I was able to get it to work using /var/lib/bla/sock > > > when I tried once more. > > > > Ok. I guess that means we don't need any particular package config fu > > here. Maybe just some documentation. > > It would be good to document where the sockets can be placed. Picking > and documenting a specific directory would ensure that, if tor later > gets locked down more, it would still be able to read sockets from that > location. 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 :) Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#846275: provide a directory for hidden service socket files
Peter Palfrader wrote: > On Sun, 18 Dec 2016, Joey Hess wrote: > > > But, I was able to get it to work using /var/lib/bla/sock > > when I tried once more. > > Ok. I guess that means we don't need any particular package config fu > here. Maybe just some documentation. It would be good to document where the sockets can be placed. Picking and documenting a specific directory would ensure that, if tor later gets locked down more, it would still be able to read sockets from that location. -- see shy jo signature.asc Description: PGP signature
Bug#846275: provide a directory for hidden service socket files
On Sun, 18 Dec 2016, Joey Hess wrote: > But, I was able to get it to work using /var/lib/bla/sock > when I tried once more. Ok. I guess that means we don't need any particular package config fu here. Maybe just some documentation. > (Still don't see how the apparmor config would let it read > /var/lib/bla/sock tho.) Well, it's not a file access. Sockets share the namespace, but they are really nothing like files. I'll grant you, I was suprised as well, but it's not entirely unreasonable. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#846275: provide a directory for hidden service socket files
Peter Palfrader wrote: > Can you retry with an info level log (see Tor#21019[1]), and maybe > strace -p -e connect the process while you're at it? > > Also, which kernel and which systemd? > > I had tried it on sid, using systemd 232-8, tor 0.2.9.7-rc-dev-.., > and 4.8.0-2-amd64 with apparmor enabled to boot. Here are the versions on the two systems I've tried: linux 4.8.0-2-amd64linux 4.6.0-1-amd64 systemd 232-7 systemd 232-3 tor 0.2.8.11 tor 0.2.8.9 Neither system has apparmor* packages installed. But, I was able to get it to work using /var/lib/bla/sock when I tried once more. Beginning to think that it's not related to filesystem perms, and is some intermittent or timing related problem getting the onion address published or querying it. I can consistently reproduce the problem by adding a new hidden service, starting up tor, and trying to connect to its onion address from the same system within about 1 minute. The telnet hangs, and this shows in the log: Dec 18 18:23:29.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID '[scrubbed]' Dec 18 18:23:29.000 [info] connection_ap_handshake_rewrite_and_attach(): Unknown descriptor [scrubbed]. Fetching. Dec 18 18:23:29.000 [debug] rend_client_refetch_v2_renddesc(): Fetching v2 rendezvous descriptor for service [scrubbed] Dec 18 18:23:29.000 [info] pick_hsdir(): Could not pick one of the responsible hidden service directories, because we requested them all recently without success. (Still don't see how the apparmor config would let it read /var/lib/bla/sock tho.) -- see shy jo signature.asc Description: PGP signature
Bug#846275: provide a directory for hidden service socket files
On Sat, 17 Dec 2016, Joey Hess wrote: > Peter Palfrader wrote: > > So, maybe I'm doing something wrong, but I have configured a hidden > > service socket in /var/lib/bla/sock, and I can access it just fine > > without listing that directory in either the apparmor nor the systemd > > service file. > > root@elephant:~> tail -n 2 /etc/tor/torrc > HiddenServiceDir /var/lib/tor/tesths > HiddenServicePort unix:/var/lib/bla/sock > root@elephant:~> service tor restart # waited for it to finish bootstrap > root@elephant:~> cd /var/lib > root@elephant:/var/lib> mkdir bla > root@elephant:/var/lib> cd bla > root@elephant:/var/lib/bla> socat UNIX-LISTEN:sock STDIO & > root@elephant:/var/lib/bla> chmod 777 sock > root@elephant:/var/lib/bla> ls -l sock > srwxrwxrwx 1 root root 0 Dec 17 18:38 sock= > root@elephant:/var/lib/bla> ls -ld `pwd` > drwxr-xr-x 2 root root 4096 Dec 17 18:42 /var/lib/bla/ > root@elephant:/var/lib/bla> cat /var/lib/tor/tesths/hostname > r7ymlfhfbpp5cfny.onion > root@elephant:/var/lib/bla> torsocks telnet r7ymlfhfbpp5cfny.onion > Trying 127.42.42.0... > > The telnet never connects. Tor is silently refusing to use /var/lib/bla/sock. > > Following the exact same procedure, but with /etc/tor/sock as the socket, > the telnet connects successfully. > > Note that this only seems to happen when tor is started by systemd. > When I run the daemon manually, it is able to use sockets elsewhere. > My assumption, which may be wrong, is that systemd is loading the > apparmor config. There may be other situations where that does not happen; > dunno. > > Complete tor log after the transcript above: > > Dec 17 22:49:31.000 [notice] Tor 0.2.8.9 (git-cabd4ef300c6b3d6) opening log > file. Can you retry with an info level log (see Tor#21019[1]), and maybe strace -p -e connect the process while you're at it? Also, which kernel and which systemd? I had tried it on sid, using systemd 232-8, tor 0.2.9.7-rc-dev-.., and 4.8.0-2-amd64 with apparmor enabled to boot. | HiddenServiceDir /var/lib/tor/other_hidden_service/ | HiddenServicePort 80 unix:/var/lib/bla/sock And } socat UNIX-LISTEN:/var/lib/bla/sock,mode=0666,fork - makes ] torsocks telnet .onion 80 connect to the socat. Also works for me using 0.2.8.11-2 from sid with apparmor disabled. I also tried a socket in /home/weasel, but that didn't work (probably due to ProtectHome=yes). Aloha, 1: https://bugs.torproject.org/21019 -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#846275: provide a directory for hidden service socket files
Peter Palfrader wrote: > So, maybe I'm doing something wrong, but I have configured a hidden > service socket in /var/lib/bla/sock, and I can access it just fine > without listing that directory in either the apparmor nor the systemd > service file. root@elephant:~> tail -n 2 /etc/tor/torrc HiddenServiceDir /var/lib/tor/tesths HiddenServicePort unix:/var/lib/bla/sock root@elephant:~> service tor restart # waited for it to finish bootstrap root@elephant:~> cd /var/lib root@elephant:/var/lib> mkdir bla root@elephant:/var/lib> cd bla root@elephant:/var/lib/bla> socat UNIX-LISTEN:sock STDIO & root@elephant:/var/lib/bla> chmod 777 sock root@elephant:/var/lib/bla> ls -l sock srwxrwxrwx 1 root root 0 Dec 17 18:38 sock= root@elephant:/var/lib/bla> ls -ld `pwd` drwxr-xr-x 2 root root 4096 Dec 17 18:42 /var/lib/bla/ root@elephant:/var/lib/bla> cat /var/lib/tor/tesths/hostname r7ymlfhfbpp5cfny.onion root@elephant:/var/lib/bla> torsocks telnet r7ymlfhfbpp5cfny.onion Trying 127.42.42.0... The telnet never connects. Tor is silently refusing to use /var/lib/bla/sock. Following the exact same procedure, but with /etc/tor/sock as the socket, the telnet connects successfully. Note that this only seems to happen when tor is started by systemd. When I run the daemon manually, it is able to use sockets elsewhere. My assumption, which may be wrong, is that systemd is loading the apparmor config. There may be other situations where that does not happen; dunno. Complete tor log after the transcript above: Dec 17 22:49:31.000 [notice] Tor 0.2.8.9 (git-cabd4ef300c6b3d6) opening log file. Dec 17 22:49:31.330 [notice] Tor v0.2.8.9 (git-cabd4ef300c6b3d6) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2j and Zlib 1.2.8. Dec 17 22:49:31.331 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Dec 17 22:49:31.332 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Dec 17 22:49:31.332 [notice] Read configuration file "/etc/tor/torrc". Dec 17 22:49:31.340 [notice] Opening Socks listener on 127.0.0.1:9050 Dec 17 22:49:31.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Dec 17 22:49:31.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Dec 17 22:49:31.000 [notice] Bootstrapped 0%: Starting Dec 17 22:49:32.000 [notice] Bootstrapped 80%: Connecting to the Tor network Dec 17 22:49:32.000 [notice] Signaled readiness to systemd Dec 17 22:49:32.000 [notice] Opening Socks listener on /var/run/tor/socks Dec 17 22:49:32.000 [notice] Opening Control listener on /var/run/tor/control Dec 17 22:49:33.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Dec 17 22:49:33.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Dec 17 22:49:33.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Dec 17 22:49:33.000 [notice] Bootstrapped 100%: Done -- see shy jo signature.asc Description: PGP signature
Bug#846275: provide a directory for hidden service socket files
On Tue, 29 Nov 2016, Joey Hess wrote: > 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. > 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. So, maybe I'm doing something wrong, but I have configured a hidden service socket in /var/lib/bla/sock, and I can access it just fine without listing that directory in either the apparmor nor the systemd service file. It seems like connect() is not governed by the usual file level restrictions imposed by systemd and apparmor. If that is indeed the case, then the admin is free to create listening sockets in /var as they please, and have e.g. a webfu socket in /var/lib/webfu. Do we need to specify a directory by the Tor package infrastructure if neither the apparmor nor the systemd service files require modification? Or am I missing something here? -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#846275: provide a directory for hidden service socket files
Peter Palfrader wrote:
> If we call it tor_hidden_service_sockets, then the onionshare usecase is
> not really covered by that name. However, I'm also not sure that it's a
> valid use-case - it probably ought to put the hidden service directory
> into /var/lib/tor and use the control interface to learn the hostname.
> Or use ephemeral hidden services via the control interface.
I can't speak for the onionshare developers, but the control interface
is not enabled by default, and can't be easily automatically enabled,
which makes it unappealing to depend on it if you can get things working
another way. There may be a permissions problem with them using
/var/lib/tor for the hidden service directory too.
Whether it makes sense to also cater to the onionshare needs with this
directory, or limit it to the hidden service socket use case,
I leave up to you.
> With the top directory not having any user specific modes, different tor
> instances can share that tree. I wonder if we still want
> /var/lib/tor-onion-sockets/{default,foo,bar} so that we get
> systemd protection and prevent a tor instance from accessing another
> instances's tree.
The permissions probably prevent such problems, at least if they are set
up as in my example with the socket file for a hidden service in a
directory that only the tor instance that serves it (and the user that
runs the service) can read.
But, it couldn't hurt to separate the directories and lock it down more.
--
see shy jo
signature.asc
Description: PGP signature
Bug#846275: provide a directory for hidden service socket files
On Thu, 08 Dec 2016, Joey Hess wrote:
> > Do we want directory shared across all tor instances, or do we want a
> > different one for every instance?
>
> The only tor instance I am familar with, aside from the system tor, is
> torbrowser's instance.
tor-instance-create(8) lets you create other instances of tor. They
have their own user, their own data directory, their own configuration.
This is useful if you want to run say a relay and also provide a hidden
service on your host.
> Actually, I can't create a socket file owned by debian-tor, and I need
> to be the one to create the socket (when my hidden service binds it).
> So, it would really look like this:
>·
> drwxr-xr-x root root /var/lib/tor_hidden_service_sockets
> drwxr-x--- joey debian-tor /var/lib/tor_hidden_service_sockets/joeyservice
> -rw-r--r-- joey joey
> /var/lib/tor_hidden_service_sockets/joeyservice/socket
>·
> This still only lets debian-tor read from the socket due to the
> permissions of the directory, which is good.
If we call it tor_hidden_service_sockets, then the onionshare usecase is
not really covered by that name. However, I'm also not sure that it's a
valid use-case - it probably ought to put the hidden service directory
into /var/lib/tor and use the control interface to learn the hostname.
Or use ephemeral hidden services via the control interface.
With the top directory not having any user specific modes, different tor
instances can share that tree. I wonder if we still want
/var/lib/tor-onion-sockets/{default,foo,bar} so that we get
systemd protection and prevent a tor instance from accessing another
instances's tree.
> Shipping the directory would be a good indication that this version of
> tor supports it. Otherwise a hidden service installer would need to look
> at version numbers or the apparmor config to guess.
>
> Also, shipping the directory would let you pick the best permissions for it.
Good reasons, thanks.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
Bug#846275: provide a directory for hidden service socket files
Peter Palfrader wrote: > I do like the idea. Do you have any suggestions on naming it? Well, the directory should only contain unix socket files for tor hidden services, so something like /var/lib/tor_hidden_service_sockets? (Path should not be too long due to the severe length limitations on paths to unix sockets..) > Do we want directory shared across all tor instances, or do we want a > different one for every instance? The only tor instance I am familar with, aside from the system tor, is torbrowser's instance. AFAIK the latter runs entirely as the user who started the browser, and uses a separate tor directory tree in their HOME, so system-wide directories are probably not useful to it. The hidden service socket directory needs to be readable by debian-tor, and by whatever set of users hidden services run as. That probably means world readable. Each hidden service can have a subdirectory in it, which need only to be readable by debian-tor and writable by the particular user who runs the hidden service. drwxr-xr-x root root /var/lib/tor_hidden_service_sockets drwxr-x--- joey debian-tor /var/lib/tor_hidden_service_sockets/joeyservice -rw-r- joey debian-tor /var/lib/tor_hidden_service_sockets/joeyservice/socket If another instance of the system tor was run for some reason, as a different user than debian-tor, it would thus not be able to access the sockets for hidden services served by debian-tor. It could use the /var/lib/tor_hidden_service_sockets directory in the same way with subdirs for the hidden services it serves. (Is it a problem that in this example user joey can now store data under /var? Well, I can already write to /var/mail/joey, and to some nethack bones files and of course to /var/tmp/. This would be the first time I was able to write to files in /var/lib/ except indirectly via crontab -e. It could be a concern if the admin enforces user disk quotas for /home, but they should probably also have quotas on /var due to the other ways for users to write there.) > Should we actually ship the directory, or would it be sufficient to just > make the apparmor and systemd restrictions allow that directory and have > the admin create it when they need it? Shipping the directory would be a good indication that this version of tor supports it. Otherwise a hidden service installer would need to look at version numbers or the apparmor config to guess. Also, shipping the directory would let you pick the best permissions for it. -- see shy jo signature.asc Description: PGP signature
Bug#846275: FWD: Re: Bug#846275: provide a directory for hidden service socket files
Resent as apparently public libraries have smtp-eating proxies now. - Forwarded message from Joey Hess <i...@joeyh.name> - Date: Thu, 8 Dec 2016 12:43:59 -0400 From: Joey Hess <i...@joeyh.name> To: Peter Palfrader <wea...@debian.org> Cc: 846...@bugs.debian.org Subject: Re: Bug#846275: provide a directory for hidden service socket files User-Agent: NeoMutt/20161104 (1.7.1) Peter Palfrader wrote: > I do like the idea. Do you have any suggestions on naming it? Well, the directory should only contain unix socket files for tor hidden services, so something like /var/lib/tor_hidden_service_sockets? (Path should not be too long due to the severe length limitations on paths to unix sockets..) > Do we want directory shared across all tor instances, or do we want a > different one for every instance? The only tor instance I am familar with, aside from the system tor, is torbrowser's instance. AFAIK the latter runs entirely as the user who started the browser, and uses a separate tor directory tree in their HOME, so system-wide directories are probably not useful to it. The hidden service socket directory needs to be readable by debian-tor, and by whatever set of users hidden services run as. That probably means world readable. Each hidden service can have a subdirectory in it, which need only to be readable by debian-tor and writable by the particular user who runs the hidden service. drwxr-xr-x root root /var/lib/tor_hidden_service_sockets drwxr-x--- joey debian-tor /var/lib/tor_hidden_service_sockets/joeyservice -rw-r- joey debian-tor /var/lib/tor_hidden_service_sockets/joeyservice/socket If another instance of the system tor was run for some reason, as a different user than debian-tor, it would thus not be able to access the sockets for hidden services served by debian-tor. It could use the /var/lib/tor_hidden_service_sockets directory in the same way with subdirs for the hidden services it serves. (Is it a problem that in this example user joey can now store data under /var? Well, I can already write to /var/mail/joey, and to some nethack bones files and of course to /var/tmp/. This would be the first time I was able to write to files in /var/lib/ except indirectly via crontab -e. It could be a concern if the admin enforces user disk quotas for /home, but they should probably also have quotas on /var due to the other ways for users to write there.) > Should we actually ship the directory, or would it be sufficient to just > make the apparmor and systemd restrictions allow that directory and have > the admin create it when they need it? Shipping the directory would be a good indication that this version of tor supports it. Otherwise a hidden service installer would need to look at version numbers or the apparmor config to guess. Also, shipping the directory would let you pick the best permissions for it. -- see shy jo - End forwarded message - -- see shy jo signature.asc Description: PGP signature
Bug#846275: provide a directory for hidden service socket files
Joey Hess wrote: > drwxr-xr-x root root /var/lib/tor_hidden_service_sockets > drwxr-x--- joey debian-tor /var/lib/tor_hidden_service_sockets/joeyservice > -rw-r- joey debian-tor > /var/lib/tor_hidden_service_sockets/joeyservice/socket Actually, I can't create a socket file owned by debian-tor, and I need to be the one to create the socket (when my hidden service binds it). So, it would really look like this: drwxr-xr-x root root /var/lib/tor_hidden_service_sockets drwxr-x--- joey debian-tor /var/lib/tor_hidden_service_sockets/joeyservice -rw-r--r-- joey joey /var/lib/tor_hidden_service_sockets/joeyservice/socket This still only lets debian-tor read from the socket due to the permissions of the directory, which is good. -- see shy jo signature.asc Description: PGP signature
Bug#846275: provide a directory for hidden service socket files
On Tue, 29 Nov 2016, Joey Hess wrote: > 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. I do like the idea. Do you have any suggestions on naming it? Do we want directory shared across all tor instances, or do we want a different one for every instance? Should we actually ship the directory, or would it be sufficient to just make the apparmor and systemd restrictions allow that directory and have the admin create it when they need it? -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#846275: provide a directory for hidden service socket files
Joey Hess: > 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. Good idea. I'll happily adjust the AppArmor policy once a suitable location has been decided (if weasel doesn't beat me to it). Cheers, -- intrigeri
Bug#846275: provide a directory for hidden service socket files
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 libc62.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 logrotate3.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 pn mixmaster pn obfs4proxy pn obfsproxy ii socat1.7.3.1-1 pn tor-arm 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
