DataDirectoryGroupReadable and CacheDirectoryGroupReadable conflicts forcing sandboxed Tor to crash
== Problem 1
CacheDirectory is the same. On Debian it is
/var/lib/tor. If you set
DataDirectoryGroupReadable 1 in
torrc (and forget about
CacheDirectoryGroupReadable) and then restart Tor, you expect granting permissions to this directory. However, Tor will not do that, but change
drwx--S--- permission to
drwx------ for this directory (which is itself not logical---removing permissions instead of granting them). Tor will also issue a warning:
[warn] Fixing permissions on directory /var/lib/tor
Later this warning will be repeated at each startup of Tor. I think that this warning should be improved, e.g.:
[warn or err] DataDirectoryGroupReadable and CacheDirectoryGroupReadable links to the same directory. You have to set both of them to 1 of both of them to 0.
Maybe you have another suggestion (e.g., if any of these options is 1, another is 1 too).
man torrc doesn't tell anything about this conflict. It should be addressed in man page too.
== Problem 2
The situation is worse when your
DataDirectoryGroupReadable 1 CacheDirectoryGroupReadable 1 Sandbox 1
In this case Tor successfully starts, but if you issue
SIGNAL RELOAD command (e.g., using
tor-prompt), Tor immediately crashes with the log:
============================================================ T= XXXXXXXXXX (Sandbox) Caught a bad syscall attempt (syscall chmod) /usr/bin/tor(+0x1a4d66)[0x556326474d66] /lib/x86_64-linux-gnu/libc.so.6(chmod+0x7)[0x7f63c91b4807] /lib/x86_64-linux-gnu/libc.so.6(chmod+0x7)[0x7f63c91b4807] /usr/bin/tor(+0xfafed)[0x5563263cafed] /usr/bin/tor(set_options+0x2ed)[0x5563263d42dd] /usr/bin/tor(options_init_from_string+0x4c7)[0x5563263d6d97] /usr/bin/tor(options_init_from_torrc+0x471)[0x5563263d72f1] /usr/bin/tor(+0x55531)[0x556326325531] /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0xe35)[0x7f63ca776a15] /usr/bin/tor(do_main_loop+0x25f)[0x556326325e3f] /usr/bin/tor(tor_run_main+0x1165)[0x556326328315] /usr/bin/tor(tor_main+0x3a)[0x55632632032a] /usr/bin/tor(main+0x19)[0x556326320099] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f63c90fab45] /usr/bin/tor(+0x500e9)[0x5563263200e9]
Sandbox be in conflict with these option? If yes, this should be documented in man page, and Tor has to complain an error during startup.
== Problem 3
Suppose, you disable
Sandbox, but keep the options
CacheDirectoryGroupReadable in place. During start Tor sets directory permissions to
debian-tor group to list files.
If you later grant read access to any file in this directory, Tor will remove this access soon. E.g.,
state file loses its group read permission at each Tor's startup. Other files may lose it less frequently. We are trapped in the situation where
CacheDirectoryGroupReadable are useless: what's the goal to be able to read directory's content, bit be unable to read any file inside it?
Earlier it was in less conflict with different tools which control Tor, because it was recommended to run each tool on behalf of
debian-tor user. Now it is recommended to run it from another user who is a member of
debian-tor group (see discussion in [[https://trac.torproject.org/projects/tor/ticket/25890|#25890]]), but "group approach" also fails...