Hello, wanted to report that after the update to Core 132 the Tor service stops and can not be started with the tor.cgi . The first problem was /usr/bin/tor: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory which is meanwhile fixed --> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=f8c23b43b78880522c3b161d6c83ce81417c5cf4 (thanks Michael) but the persisting problem is located in the user/group switch from 'nobody' to 'tor'--> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=2df98063a246dc1f17bae7fd0e477d7f73e2319f which prevents a service start via WUI. If i change the user back to 'nobody' in 'defaults-torrc' i can start Tor again via tor.cgi . It seems that there is currently a problem with the permissions. Best, Erik
Can you provide logs? It must complain about something not being right (probably file ownerships).
Only by using the tor WUI there is nothing findable in messages nor in error_log. If i use torctrl restart (service is already stopped) i get an May 27 17:48:43 ipfire Tor[16027]: Received reload signal (hup). Reloading config and resetting internal state. May 27 17:48:43 ipfire Tor[16027]: Read configuration file "/usr/share/tor/defaults-torrc". May 27 17:48:43 ipfire Tor[16027]: Read configuration file "/etc/tor/torrc". May 27 17:48:43 ipfire Tor[16027]: ControlPort is open, but no authentication method has been configured. This means that any program on your computer can reconfigure your Tor. That's bad! You should upgrade your Tor controller as soon as possible. May 27 17:48:43 ipfire Tor[16027]: Failed to parse/validate config: While Tor is running, changing User is not allowed May 27 17:48:43 ipfire Tor[16027]: Reading config failed--see warnings above. For usage, try -h. May 27 17:48:43 ipfire Tor[16027]: Restart failed (config error?). Exiting. Best, Erik
Hi, first: Thanks for reporting. I did not get it: Does this happen with or without libseccomp? Thanks, and best regards, Peter Müller
Forget my last comment. This is another permission issue. :-/ chown tor:tor /var/lib/tor solves the problem for any setup I can reproduce here tonight. Please let me know if this helps.
Hi Peter, (In reply to Peter Müller from comment #3) > first: Thanks for reporting. your welcome. (In reply to Peter Müller from comment #4) > Forget my last comment. This is another permission issue. :-/ OK and yes you are right. > > chown tor:tor /var/lib/tor Doesn´t it need a '-R' (the 'keys' folder) ? Best, Erik
That's right, it's a permission problem. chown -r tor:tor /var/lib/tor fixes it.
(In reply to Marco Paland from comment #6) > > chown -r tor:tor /var/lib/tor > > fixes it. Typo: Of course: chown -R ...
Hi all, it seems that the update.sh misses the appropriate fix for the permissions in Core 132 --> https://forum.ipfire.org/viewtopic.php?f=52&t=22905 . Best, Erik
Can someone please send a patch - ideally today - so that we can close the core update?
Hi Michael, --> https://patchwork.ipfire.org/patch/2292/ . Best, Erik
Actually, "install.sh" _contains_ statements to create Tor user and group if necessary, and updates file permissions afterwards. It works for freshly installed Tor instances, but not for updated ones, although "update.sh" is calling the "install.sh" at some point. Weird.
https://patchwork.ipfire.org/patch/2296/
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=fa7de475fe745004b207eea07ba178b61197fe5e
This is fixed by now.