Opened 11 years ago

Last modified 7 years ago

#857 closed defect (Fixed)

Latest SVNs will not start - no log messages

Reported by: yancm Owned by:
Priority: High Milestone:
Component: Core Tor/Tor Version: 0.2.1.7-alpha
Severity: Keywords:
Cc: yancm, nickm, arma, sjmurdoch Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When I try to start the latest SVN version of tor, I receive the following console messages.
Despite the last line, there is nothing at all in the log file.

Nov 09 09:30:11.070 [notice] Tor v0.2.1.7-alpha (r17224). This is experimental software. Do not rely on it for strong anonymity. (Running on NetBSD i386)
Nov 09 09:30:11.086 [notice] Initialized libevent version 1.4.3-stable using method kqueue. Good.
Nov 09 09:30:11.088 [notice] Opening Socks listener on 192.168.1.1:9050
Nov 09 09:30:11.094 [warn] Error setting configured groups: Operation not permitted
Nov 09 09:30:11.094 [warn] Failed to parse/validate config: Problem with User value. See logs for details.
Nov 09 09:30:11.095 [err] Reading config failed--see warnings above.

[Automatically added by flyspray2trac: Operating System: BSD]

Child Tickets

Change History (6)

comment:1 Changed 11 years ago by nickm

Hm. This looks like a bug in the new, more secure, setuid logic. Tor is trying to change your groups to
the group listed in the password file for the user you configured, but for some reason it's failing.
I've updated the svn code to log a little better about what's going on in this case. Also, for better
debugging here, you can try redefining CREDENTIAL_LOG_LEVEL in compat.c from LOG_INFO to LOG_NOTICE.

comment:2 Changed 11 years ago by yancm

Hmmm indeed.

  • I discovered I had a typo in my primary user group ID in the password files...fixed that.
  • Then needed to adjust all file permissions since I just adjusted the group ID...fixed that.
  • Now I see that with my unprivileged user I am not able to reset the group of the process - that's a root only function...bummer
  • Next I try to start the tor daemon as sudo root - it detects my primary group (100), but unsets my secondary group (0) so I cannot write to /var/run/tor.pid anymore...PITA at least it starts the process.
  • OK - I've edited my /etc/rc.d/tor file to write the pid file to /usr/local/etc/tor - everything works again.

I'll agree it's more secure, but requires I sudo root before starting the daemon. I was relying too much
on being the only active user on my box and security loopholes AND I had an error in my password file.

Unless I find a new issue within an hour or so, I think it's OK to close this. Actual bugs were on my end.

Neat stuff!

comment:3 Changed 11 years ago by sjmurdoch

If I understand correctly, you were starting Tor as a non-root user, and specifying the "User" option, for the same
non-root user. Is that correct?

In this case, I don't think there is any need for you to specify the User option at all. If you omit the option,
Tor will just not attempt to modify the user or groups. The only difference is that Tor now clears the supplementary
group list, if the User option is specified, as you have noticed.

The main reason I think the User option is for is if Tor is binding to a port <1024, but still should run as a
non-root user. In other cases, I think it's better to start Tor as the intended user in the first place (e.g.
via sudo or su). Was this the reason you specified the User option, or was it something else?

comment:4 Changed 11 years ago by arma

Ok, r17232 should provide a better error message in this case:

+ log_warn(LD_GENERAL, "Error setting groups to gid %d: \"%s\". "
+ "If you set the \"User\" option, you must start Tor as root.",

I'm going to close this flyspray. Thanks!

comment:5 Changed 11 years ago by arma

flyspray2trac: bug closed.

comment:6 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.