I have installed tor from EPEL on a fresh installed CentOS7 (minimal).
After configuring a hidden service I check and validate that the service is up and running by browsing the URL generated in hostname file from the tor browser.
At this point the service is configured to start automatically using systemctl enable tor
Everything works find until I restart the service sudo systemctl restart tor. After that tor service does not star anymore logging the following error:
Directory /var/lib/tor/hidden_service_01/ cannot be read: Permission denied
hidden_service_01 folder is automatically created by the tor service when it runs the first time.
if I delete hidden_service_01 folder and start the service again. It starts up (generating a new .onion url). But once it's stopped and started again the permission error occurs again.
Why am I getting the permission error and how to I make it work?
P.S. I created a guide snippet the I used for my configuration:
https://gist.github.com/Dzoge/f059d30da77a21df1a0f29a0b5c528a2
UPDATE 1:
I have checked the folder permissions and they were:
- folder permissions are
rwx------. 2 toranon toranon - two files inside the folder are
rw-------. 1 toranon toranon
I set chmod to 770 and now folder and files all have rwxrwx---. 1 toranon toranon
I try to start tor service systemctl start tor and still get the same permission warning.
UPDATE 2:
I tried doing the same on Ubuntu server and it worked pretty well. I updated the gist as well and added a guide for ubuntu.
The problem still remains with CentOS 7.
UPDATE 3 (workaround):
Looks like a temporary workaround is to set SELinux to permissive mode. Then it works as expected.
Best Answer
If you take a look at the
tor.serviceunit, you will see that it has a command to attempt to verify the Tor configuration before starting the service.This is where things are going wrong. When this runs, the configuration fails to validate due to the permission problem noted earlier.
Eventually I traced this down to some of the hardening that systemd does here. If you'll read further in the unit file, you'll see that systemd actually runs Tor in a container, and locks down the permissions very tightly. It also removes some capabilities, so that even root cannot do some actions the root user would normally be able to do, such as read other users' files (this is known as CAP_DAC_OVERRIDE).
When we attempt to audit the failed start, we find:
What I found here is that the command to verify config was not actually changing from the root user to the toranon user before reading the configuration, so access to the directory was being denied, as systemd did not give the process CAP_DAC_OVERRIDE. You can see the user IDs were logged as
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0.So to resolve this on my system, I decided to have systemd start Tor as toranon rather than starting as root and Tor changing its own uid/gid.
User toranonsetting from/usr/share/tor/torrc-defaults.I created an override file
/etc/systemd/system/tor.service.d/override.confcontaining:It's necessary to use
PermissionsStartOnly=noto ensure that theExecStartPre=command is run under the toranon user. From the documentation:After a
systemctl daemon-reloadI was then able tosystemctl start torsuccessfully.Ultimately this (or something like it) needs to be incorporated into the Tor default config and systemd unit shipped by Fedora/EPEL, which will resolve the problem for everyone.