Tor.service boot errors?

Question

"HiddenServicePort with no preceding HiddenServiceDir directive"

errors from my syslog after updating to tor v2.8.6.1 in ubuntu 16 and rebooting:

[notice] Tor v0.2.8.6 (git-2c0d81c26eefc1f6) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g-fips and Zlib 1.2.8.
[notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
[notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
[notice] Read configuration file "/etc/tor/torrc".
[warn] HiddenServicePort with no preceding HiddenServiceDir directive
[warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.
[err] Reading config failed--see warnings above.
systemd[1]: [email protected]: Control process exited, code=exited status=1
systemd[1]: Failed to start Anonymizing overlay network for TCP.
systemd[1]: [email protected]: Unit entered failed state.
systemd[1]: [email protected]: Failed with result 'exit-code'.
systemd[1]: [email protected]: Service hold-off time over, scheduling restart.
systemd[1]: Stopped Anonymizing overlay network for TCP.
systemd[1]: Starting Anonymizing overlay network for TCP...
tor[4826]: .500 [notice] Tor v0.2.8.6 (git-2c0d81c26eefc1f6) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g-fips and Zlib 1.2.8.
tor[4826]: .500 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
tor[4826]: .500 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
tor[4826]: .500 [notice] Read configuration file "/etc/tor/torrc".
tor[4826]: .503 [warn] HiddenServicePort with no preceding HiddenServiceDir directive
tor[4826]: .504 [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.
tor[4826]: .504 [err] Reading config failed--see warnings above.
systemd[1]: [email protected]: Control process exited, code=exited status=1
systemd[1]: Failed to start Anonymizing overlay network for TCP.
systemd[1]: [email protected]: Unit entered failed state.
systemd[1]: [email protected]: Failed with result 'exit-code'.
systemd[1]: [email protected]: Service hold-off time over, scheduling restart.
systemd[1]: Stopped Anonymizing overlay network for TCP.
systemd[1]: Starting Anonymizing overlay network for TCP...
systemd-logind[3249]: Removed session c2.
systemd[1]: Stopping User Manager for UID 108...
systemd[3898]: Reached target Shutdown.
systemd[3898]: Starting Exit the Session...

tor wouldn't start. I also noticed:

apparmor="DENIED" operation="open" profile="system_tor" name="/var/lib/tor/hidden_service/" pid=5051 comm="tor" requested_mask="r" denied_mask="r" fsuid=0 ouid=122

my apparmor profile was blocking access to my hidden service dir.

$ cat /etc/apparmor.d/system_tor

owner /var/lib/tor/** rwk,

changed it to:

/var/lib/tor/** rwk,

removing "owner" fixes the issue with tor, it start without errors now.

is it generally okay to remove "owner" from the apparmor profile? is there another resolution for the syslog errors?

Answer 1

The "owner" conditional, as per the AppArmor wiki:

The owner keyword is used to make the rule conditional on object ownership. Specifically the task must have the same euid/fsuid as the object being referenced by the permission check.

The problem seems to be that the user that tor is running as (debian-tor is the default on ubuntu and other debian derivatives) is not the owner of the /var/lib/tor/hidden_service folder.

A common mistake people make is trying to create the /var/lib/tor/hidden_service folder manually, this normally results in an issue where Tor complains about the permissions on the folder and refuses to operate on it. Instead, you should just set the HiddenServiceDir directive to point to some location inside /var/lib/tor, which debian-tor should already own. It create the folder and files itself, with the appropriate permissions.

Looking at the log output: apparmor="DENIED" ...[SNIP].. fsuid=0 ouid=122, the fsuid is root (uid 0) and the process is running as (what I'm assuming is) debian-tor (uid 122). It looks like the directory isn't owned by debian-tor. You probably want that "owner" prefix, try to address the directory permissions problem (I.E. let tor handle creating it).