Dear port maintainer, Each time I upgrade my tor instance, the var/run directory gets overwritten by permissions I don't want. I monitor my tor instance with netdata, for this I need to be able to grant netdata permission (read/execute as the group _tor). So the permissions I need are 750, but when upgrading permissions are reset to 700. Is there an option to possible create the directory in the rc start script? If the directory exists, do nothing, if it doesn't, create it with the permissions 700. Or another option?
(In reply to Dries Michiels from comment #0) Hi Dries, Are you talking about permissions on /var/run or /var/run/tor? Yuri
A commit references this bug: Author: yuri Date: Fri Dec 25 10:19:36 UTC 2020 New revision: 559234 URL: https://svnweb.freebsd.org/changeset/ports/559234 Log: security/tor: Allow _tor group to read tor files and directories under /var PR: 252127 Requested by: Dries Michiels <driesm.michiels@gmail.com> Changes: head/security/tor/Makefile head/security/tor/pkg-plist
Fixes. Thanks for your report!
Hi Yuri, its not so simple to just give them these new permissions. This fix will hunt others. was indeed talking about /var/run/tor, for access to the socket. The problem with the current fix is that other users not wanting the permissions will not be able to start the tor instance if they have not put the following in torrc: ControlSocket /var/run/tor/tor.sock GroupWritable RelaxDirModeCheck
Something analog like this will help for everyone (not tested yet): tor_precmd() { # Make sure we have our RUNDIR [ -d ${run_dir} ] || install -d -m 0700 -g _tor -o _tor -- ${run_dir} } This will not overwrite the defaults (0700), and if users change the default they will not be hunted by the package list because we check if it exists or not. (and do nothing if it does)
Reopening.
On my FreeBSD 12.2 jail I had this: - before upgrade: permissions 700 for /var/run/tor - after upgrade: permissions 750 - after restarting tor: permissions set back to 700 Nothing special in /usr/local/etc/tor/torrc I guess: SocksPort 0 ORPort 9001 ORPort [2a10:****]:9001 Nickname ymkeo ContactInfo rene <rene0@****> DirPort 9030 ExitPolicy reject *:* ExitPolicy reject6 *:* ControlPort 9051 HashedControlPassword 16:***** Log notice file /var/log/tor/tor BandwidthRate 750 KBytes BandwidthBurst 750 KBytes
So the tor daemon fixes the permissions by itself if the user does not allow the more relaxed permissions explicitly (like GroupWritable RelaxDirModeCheck in torrc). Then we might close this PR as that behavior is somewhat OK. I really thought it would refuse to start, at least that was the behavior a while back. Maybe they changed that upstream. Given the "no comments this breaks my tor instance from starting since this patch landed" there is probably no problem related to the initial fix.
I'm gonna close this PR given that no more comments have been posted on the bug report from other users with respect to this change.