| Message ID | z7bo5cNBBIFwYrhxbJfvgpqSV8WXpQlpP9NKuZkyGvuXUP7iVJ86yHGgPuVlYgAmxas9QM_VF6XBy5AiktHlNubv_a6RMMwqIisIFzMHW7A=@protonmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#47155] gnu: Respect DataDirectoryGroupReadable option of tor. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
On Mon, 2021-03-15 at 11:15 +0000, raid5atemyhomework via Guix-patches via wrote: > Currently, if you set DataDirectoryGroupReadable 1 in your torrc, What are the reasons for setting DataDirectoryGroupReadable 1? > it will be respected only if tor is started up. IIUC, tor will adjust the permissions of the directory to make it group readable (while Guix' activation code creates the directory group-unreadable). > If you reconfigure your OS without restarting the tor service, > the directory permissions are reset due to the activation code being > re-run and resetting the directory permissions. > > This change simply does not chmod if the directory already exists. I believe it would be more transparent to introduce a (data-directory-group-readable? #t/#f), with #f as default, to tor-configuration (adjusting tor-configuration->torrc) and change the permission bits passed to chmod appropriately. (Documentation & reproducible system configuration & one integrated system (in the software sense) and all that) Greetings, Maxime.
> On Mon, 2021-03-15 at 11:15 +0000, raid5atemyhomework via Guix-patches via wrote: > > > Currently, if you set DataDirectoryGroupReadable 1 in your torrc, > > What are the reasons for setting DataDirectoryGroupReadable 1? > When using cookie-based authentication, the cookie file is traditionally placed in the data directory. If the directory is not accessible from group, then only the `tor` user can access the cookie and control `tor`. With this option, the cookie can be accessed by members of the `tor` group. > > it will be respected only if tor is started up. > > IIUC, tor will adjust the permissions of the directory to make it > group readable (while Guix' activation code creates the directory > group-unreadable). Correct. However, when doing a `guix system reconfigure`, the activation code will be called again, which changes the directory back to group unreadable, without restarting tor. `tor` itself will only set the permissions when it starts up, and will ignore the permissions while running. > > > If you reconfigure your OS without restarting the tor service, > > the directory permissions are reset due to the activation code being > > re-run and resetting the directory permissions. > > This change simply does not chmod if the directory already exists. > > I believe it would be more transparent to introduce a > (data-directory-group-readable? #t/#f), with #f as default, > to tor-configuration (adjusting tor-configuration->torrc) > and change the permission bits passed to chmod appropriately. > > (Documentation & reproducible system configuration & one integrated > system (in the software sense) and all that) Possibly. Thanks raid5atemyhomework
>+ (when #$control-port? >+ (format port >+ "\ >+ControlPort ~a >+CookieAuthentication 1 >+CookieAuthFileGroupReadable 1 >+DataDirectoryGroupReadable 1\n" Maybe instead of a port, we can have separate options for `control-port', and `cookie-authentication?'. As IIUC cookie authentication can still be used with a control UNIX domain socket. >+ #$(if (eq? control-port? #t) >+ 9051 >+ control-port?))) As a side note, the `if' can be removed and the port put in place into the string directly. But would prefer an option in the configuration record for the control port. — Jean-Pierre De Jesus DIAZ
diff --git a/gnu/services/networking.scm b/gnu/services/networking.scm index 231a9f66c7..65d2d39f0b 100644 --- a/gnu/services/networking.scm +++ b/gnu/services/networking.scm @@ -881,10 +881,16 @@ HiddenServicePort ~a ~a~%" ;; of the "tor" group will be able to use the SOCKS socket. (chmod "/var/run/tor" #o750) - ;; Allow Tor to access the hidden services' directories. - (mkdir-p "/var/lib/tor") + ;; If the directory already exists, do not chmod it again; the user + ;; might have set "DataDirectoryGroupReadable 1" in the torrc. + ;; Without this check, a `guix system reconfigure` will cause the + ;; directory to lose group permissions until Tor is restarted, even + ;; if changes to the operating-system were unrelated to Tor. + (unless (file-exists? "/var/lib/tor") + (mkdir-p "/var/lib/tor") + ;; Allow only Tor and root to access the hidden services' directories. + (chmod "/var/lib/tor" #o700)) (chown "/var/lib/tor" (passwd:uid %user) (passwd:gid %user)) - (chmod "/var/lib/tor" #o700) ;; Make sure /var/lib is accessible to the 'tor' user. (chmod "/var/lib" #o755)
Currently, if you set DataDirectoryGroupReadable 1 in your torrc, it will be respected only if tor is started up. If you reconfigure your OS without restarting the tor service, the directory permissions are reset due to the activation code being re-run and resetting the directory permissions. This change simply does not chmod if the directory already exists. Thanks raid5atemyhomework From d6037c59e642eaafebe43996e7419e1b58fee616 Mon Sep 17 00:00:00 2001 From: raid5atemyhomework <raid5atemyhomework@protonmail.com> Date: Mon, 15 Mar 2021 19:10:01 +0800 Subject: [PATCH] gnu: Respect DataDirectoryGroupReadable option of tor. * gnu/services/networking.scm (tor-activation): Do not change permissions of tor data directory if it already exists. --- gnu/services/networking.scm | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) -- 2.30.2