Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#68157 - [tor] Directory /var/lib/tor/hidden_service/ cannot be read: Permission denied

Attached to Project: Community Packages
Opened by ilf (ilf) - Thursday, 08 October 2020, 14:18 GMT
Last edited by freswa (frederik) - Thursday, 08 October 2020, 19:20 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To freswa (frederik)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
After upggrading tor from 0.4.4.5-1 to 0.4.4.5-3, it fails to start, with this error message:

[warn] Directory /var/lib/tor/hidden_service/ cannot be read: Permission denied
[warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.
[err] Reading config failed--see warnings above.

Disabling the Onion Service by commenting out these two lines in my config makes the daemon start:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80

The permissions seem correct:

% sudo ls -la /var/lib/tor/hidden_service/
drwx------ 3 tor tor 4096 Oct 1 05:30 .
drwx------ 5 tor tor 4096 Oct 1 05:14 ..
drwx------ 2 tor tor 4096 Apr 1 2019 authorized_clients
-rw------- 1 tor tor 63 Oct 1 05:30 hostname
-rw------- 1 tor tor 64 Apr 1 2019 hs_ed25519_public_key
-rw------- 1 tor tor 96 Apr 1 2019 hs_ed25519_secret_key

Maybe related to some AppArmor or other Sandbox setting?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862993
https://trac.torproject.org/projects/tor/ticket/20007

Additional info:
* package version(s): 0.4.4.5-
This task depends upon

Closed by  freswa (frederik)
Thursday, 08 October 2020, 19:20 GMT
Reason for closing:  Fixed
Additional comments about closing:  tor-0.4.4.5-4
Comment by freswa (frederik) - Thursday, 08 October 2020, 14:46 GMT
Did you merge the pacnews?
Comment by ilf (ilf) - Thursday, 08 October 2020, 15:13 GMT
Yes:

% grep -v "^#" /etc/tor/torrc | grep .
User tor
Log notice syslog
DataDirectory /var/lib/tor
Comment by Oleksandr Natalenko (post-factum) - Thursday, 08 October 2020, 15:18 GMT
Granting CAP_DAC_OVERRIDE via CapabilityBoundingSet solves this issue.
Comment by York-Simon Johannsen (YoSiJo) - Thursday, 08 October 2020, 17:36 GMT
Same problem, solution for me is this:
```
cat /etc/systemd/system/tor.service.d/override.conf
[Service]
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE
```
Comment by freswa (frederik) - Thursday, 08 October 2020, 18:12 GMT
Could you please check if setting CAP_DAC_READ_SEARCH is sufficient?
Comment by Oleksandr Natalenko (post-factum) - Thursday, 08 October 2020, 18:15 GMT
Yes, CAP_DAC_READ_SEARCH is sufficient.
Comment by ilf (ilf) - Thursday, 08 October 2020, 18:23 GMT
Debian also used CAP_DAC_READ_SEARCH, back in 2017:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862993#29
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=862993;filename=0001-AppArmor-allow-dac_read_search-capability-instead-of.patch;msg=20
Comment by York-Simon Johannsen (YoSiJo) - Thursday, 08 October 2020, 18:33 GMT
Yes, for a existent hidden_service and a new.

Loading...