[bug#47155] gnu: Respect DataDirectoryGroupReadable option of tor.

> > 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)


But really though, the primary reason for this is to use the "cookie" authentication scheme with a control port on 9051.  This is supported by most daemons, as the "control unix socket" (that is currently supported by `control-socket?` option) seems to be relatively new (Tor 0.2.7.1).

This requires adding:

    ControlPort 9051
    CookieAuthentication 1
    CookieAuthFileGroupReadable 1
    DataDirectoryGroupReadable 1

In https://issues.guix.gnu.org/46549 which implements `control-socket?` the author expressed doubt as to the safety of this mechanism.  Looking at the Tor manpage regarding `ControlPort`:

```
Note: unless you also specify one or more of HashedControlPassword or CookieAuthentication, setting this option will cause Tor to allow any process on the local
host to control it. (Setting both authentication methods means either method is sufficient to authenticate to Tor.) This option is required for many Tor controllers; most use
the value of 9051.
```

Basically, this is safe as long as you use *either* `HashedControlPassword` *or* `CookieAuthentication` *or* both; in the case of `CookieAuthentication` only users with read access to the cookie file can access it.  Nearly every daemon that needs control access over Tor (usually to set up their own hidden service using their own privkey) expects `CookieAuthentication` and reads from `/var/lib/tor/control_auth-_cookie`, which requires that `/var/lib/tor` be readable (else it can't look up the filename).  It becomes just as safe as the control-unix-socket option, as that is similarly gated by file permissions.

Note in particular that Bitcoin Core supports `ControlPort` and not `ControlSocket`, so this is needed for Bitcoin Core support.  From what I can see more daemons support `ControlPort` than `ControlSocket`.


Thanks
raid5atemyhomework


From d9bea7635594654e1e631e4db55422c511f0220a Mon Sep 17 00:00:00 2001
From: raid5atemyhomework <raid5atemyhomework@protonmail.com>
Date: Sat, 27 Mar 2021 14:29:31 +0800
Subject: [PATCH] gnu: Add 'control-port?' setting to Tor.

* gnu/services/networking.scm (tor-configuration): Add `control-port?` field.
(tor-configuration->torrc): Support `control-port?` field.
(tor-activation): Allow group access to data directory if `control-port?`.
* doc/guix.texi (Networking Services)[Tor]: Describe new `control-port?` field.
---
 doc/guix.texi               | 13 +++++++++++++
 gnu/services/networking.scm | 24 +++++++++++++++++++++---
 2 files changed, 34 insertions(+), 3 deletions(-)

--
2.31.0

On Sat, 2021-03-27 at 06:37 +0000, raid5atemyhomework wrote:
> > > 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)
> 
> But really though, the primary reason for this is to use the "cookie"
> authentication scheme with a control port on 9051.  This is supported
> by most daemons, as the "control unix socket" (that is currently supported
> by `control-socket?` option) seems to be relatively new (Tor 0.2.7.1).
> 
> This requires adding:
> 
>     ControlPort 9051
>     CookieAuthentication 1
>     CookieAuthFileGroupReadable 1
>     DataDirectoryGroupReadable 1
> 
> In https://issues.guix.gnu.org/46549 which implements `control-socket?` the
> author expressed doubt as to the safety of this mechanism.  Looking at the Tor
>  manpage regarding `ControlPort`:
> 
> ```
> Note: unless you also specify one or more of HashedControlPassword or CookieAuthentication,
> setting this option will cause Tor to allow any process on the local
> host to control it. (Setting both authentication methods means either method is sufficient
> to authenticate to Tor.) This option is required for many Tor controllers; most use
> the value of 9051.
> ```
> 
> Basically, this is safe as long as you use *either* `HashedControlPassword` *or*
> `CookieAuthentication` *or* both; in the case of `CookieAuthentication` only users
> with read access to the cookie file can access it.  Nearly every daemon that needs
> control access over Tor (usually to set up their own hidden service using their own
> privkey) expects `CookieAuthentication` and reads from `/var/lib/tor/control_auth-_cookie`,
> which requires that `/var/lib/tor` be readable (else it can't look up the filename).  It
> becomes just as safe as the control-unix-socket option, as that is similarly gated by
> file permissions.

I believe this addresses the security concerns Christopher Lemmer Webber had.

> Note in particular that Bitcoin Core supports `ControlPort` and not `ControlSocket`, so
> this is needed for Bitcoin Core support.  From what I can see more daemons support
> `ControlPort` than `ControlSocket`.

Ok, but take a look at
<https://gitlab.torproject.org/legacy/trac/-/wikis/doc/bitcoin>.
Maybe its out of date though: <https://blog.torproject.org/tor-heart-cryptocurrencies>

This patch looks good to me, except for some minor aesthetic issues in the commit message.
I ran "make system-check TESTS=tor" with this patch, which succeeded.

> Thanks
> raid5atemyhomework
> 
> 
> From d9bea7635594654e1e631e4db55422c511f0220a Mon Sep 17 00:00:00 2001
> From: raid5atemyhomework <raid5atemyhomework@protonmail.com>
> Date: Sat, 27 Mar 2021 14:29:31 +0800
> Subject: [PATCH] gnu: Add 'control-port?' setting to Tor.
> 
> * gnu/services/networking.scm (tor-configuration): Add `control-port?` field.
> (tor-configuration->torrc): Support `control-port?` field.
> (tor-activation): Allow group access to data directory if `control-port?`.
> * doc/guix.texi (Networking Services)[Tor]: Describe new `control-port?` field.

Usually we `quote', 'quote', "quote" or ‘quote’, but never `quote`.
I recommend 'quote', as in

commit 43937666ba6975b6c847be8e67cecd781ce27049
Author: Ludovic Courtès <ludo@gnu.org>
Date:   Fri Mar 19 14:23:57 2021 +0100

    download: 'tls-wrap' treats premature TLS termination as EOF.
    
    This is a backport of Guile commit
    076276c4f580368b4106316a77752d69c8f1494a.
    
    * guix/build/download.scm (tls-wrap)[read!]: Wrap 'get-bytevector-n!'
    call in 'catch' and handle 'error/premature-termination' GnuTLS errors.

Greetings, Maxime.