Bug 252127 - security/tor: Remove /var/run/tor directory out of package list
Summary: security/tor: Remove /var/run/tor directory out of package list
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Yuri Victorovich
Depends on:
Reported: 2020-12-25 10:06 UTC by Dries Michiels
Modified: 2021-02-21 11:28 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (yuri)


Note You need to log in before you can comment on or make changes to this bug.
Description Dries Michiels 2020-12-25 10:06:02 UTC
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?
Comment 1 Yuri Victorovich freebsd_committer 2020-12-25 10:13:44 UTC
(In reply to Dries Michiels from comment #0)

Hi Dries,

Are you talking about permissions on /var/run or /var/run/tor?

Comment 2 commit-hook freebsd_committer 2020-12-25 10:19:47 UTC
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

  security/tor: Allow _tor group to read tor files and directories under /var

  PR:		252127
  Requested by:	Dries Michiels <driesm.michiels@gmail.com>

Comment 3 Yuri Victorovich freebsd_committer 2020-12-25 10:19:57 UTC

Thanks for your report!
Comment 4 Dries Michiels 2020-12-25 10:39:59 UTC
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
Comment 5 Dries Michiels 2020-12-25 10:45:30 UTC
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)
Comment 6 Yuri Victorovich freebsd_committer 2020-12-25 11:11:15 UTC
Comment 7 Rene Ladan freebsd_committer 2021-01-09 14:52:13 UTC
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
Comment 8 Dries Michiels 2021-02-21 11:28:12 UTC
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.