Opened 11 years ago

Last modified 7 years ago

#882 closed defect (Implemented)

tor-devel crashes on startup

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

Description

The latest test version of tor-devel-0.2.1.7-alpha is buggy on startup.
Because Linux users seems to have no problem, I assume this is a
special BSD bug.

Starting tor.
Dec 04 19:45:29.165 [notice] Tor v0.2.1.7-alpha (r17216). This is experimental software. Do not rely on it for strong anonymity. (Running on FreeBSD i386)
Dec 04 19:45:29.168 [warn] You specified a public address '0' for a SOCKS proxy. Other people on the Internet might find your computer and use it as an open SOCKS proxy. Please don't allow this unless you have a good reason.
Dec 04 19:45:29.172 [notice] Initialized libevent version 1.4.8-stable using method kqueue. Good.
Dec 04 19:45:29.173 [notice] Opening OR listener on 0.0.0.0:9001
Dec 04 19:45:29.173 [notice] Opening Socks listener on 0:9050
Dec 04 19:45:29.176 [warn] Error setting configured groups: Operation not permitted
Dec 04 19:45:29.177 [warn] Failed to parse/validate config: Problem with User value. See logs for details.
Dec 04 19:45:29.177 [err] Reading config failed--see warnings above.

In comparision to older versions of tor (e.g. 0.2.0.32, 0.2.1.5.alpha,
0.2.1.6.alpha) the last three lines never did occur.

Further, there are no 'logs for details' where I can see more infos. The
files debug.log and notices.log will be not created/touched.

[Automatically added by flyspray2trac: Operating System: BSD]

Child Tickets

Attachments (1)

torrc (7.7 KB) - added by bsdtechie 11 years ago.

Download all attachments as: .zip

Change History (15)

Changed 11 years ago by bsdtechie

Attachment: torrc added

comment:1 Changed 11 years ago by bsdtechie

See torrc in attachments.

comment:2 Changed 11 years ago by arma

Are you using a BSD package? Which BSD? Which package?

Are you certain that 0.2.0.32 doesn't have a problem? It just came out,
and has mostly the same fixes as 0.2.0.7-alpha.

comment:3 Changed 11 years ago by nickm

Strange. If I'm looking at the right torrc, it has no User or Group listed. This is weird, since if options->User is
NULL in options_act_reversible(), the switch_id() function should never be called, and so setgroups() should never be
invoked.

So, two big mysteries:

First, why is switch_id() being called? Are you launching Tor from the command line, or from
some init script? In the latter case, what arguments is Tor getting launched with?

Second, why isn't it working? What user is launching Tor: Root, or somebody else?

We should also check out the BSD documentation for setgroups to make sure it works the same as it does elsewhere.

comment:4 Changed 11 years ago by bsdtechie

Are you using a BSD package? Which BSD? Which package?

FreeBSD 6.4RC2, downloaded Tor from the 'ports tree collection', then compiled,
linked and installed in standard freebsd style with a simple "make install"
command.

Are you certain that 0.2.0.32 doesn't have a problem? It just came out,
and has mostly the same fixes as 0.2.0.7-alpha.

Definitely, 0.2.0.32_2 is OK and 0.2.7.1.a is NOK. Meanwhile I have switched a
zillion times from tor to tor-devel and back again.

If I'm looking at the right torrc, it has no User or Group listed.

/etc/passwd entry:
_tor:*:256:256:Tor Daemon:/var/db/tor:/bin/sh

/etc/group entry:
_tor:*:256:

Are you launching Tor from the command line, or from
some init script?

launching it from the init script, standard BSD style: "/usr/local/etc/rc.d/tor start"

Second, why isn't it working? What user is launching Tor: Root, or somebody else?

Should be user "_tor", nobody else.

If Tor is working the process looks like that:

_tor 11223 0.0 6.8 13412 12720 ?? S 5:39PM 0:07.01 /usr/local/bin/tor
-f /usr/local/etc/tor/torrc --PidFile /var/run/tor/tor.pid --RunAsDaemon 1
--DataDirectory /var/db/tor --Log notice file /var/log/tor

Just an idea: Look at the minor version number "_2" (of 0.2.0.32_2) and
compare the comments of tor and tor-devel in:

http://www.freshports.org/security/tor-devel/
http://www.freshports.org/security/tor

then it is visible that there is a difference in group and user handling
since the last two fixes from tor 0.2.0.32, 0.2.032_1 to 0.2.32_2.

Is it a bug in the script of the BSD ports committer of tor-devel? Should
I contact him?

comment:5 Changed 11 years ago by bsdtechie

Oops.

since the last two fixes from tor 0.2.0.32, 0.2.032_1 to 0.2.32_2.

since the last three fixes from tor-0.2.0.32, tor-0.2.0.32_1 to tor-0.2.0.32_2.

comment:6 Changed 11 years ago by arma

Yes, it looks like the 0.2.1.7-alpha bsd packages need some patching like the
0.2.0.32 bsd packages got.

comment:7 Changed 11 years ago by nickm

The FreshPorts page for 0.2.0.32 says:

  • Remove --User param from initialization since rc(8) uses su(1) when a var ${name}_user is defined (su -m user). When --User param is defined in this scenario, tor don't start because when you use --User param you must to start it with root user.

Perhaps we could get smarter about what to do when we're acted to su to the user that we already are,
and treat it as a "warn and continue" condition rather than a "error and exit."

comment:8 Changed 11 years ago by arma

Nick: see the "handle-double-changes.patch" attachment at the bottom of
https://bugs.torproject.org/flyspray/index.php?do=details&id=848&area=attachments#tabs

That should do roughly what you want.

However, Steven and I chatted about it earlier and decided then not to put
it in. I think that's because in the current case we know that we drop groups,
whereas if we put that patch in then if Tor ran as arma and set 'User arma',
I would fail to drop my groups because I don't have the permissions to do that.

So I would end up in a different security situation, and not ever realize it.
That didn't seem like a good move long-term, whereas getting all the random
people with scripts to fix their scripts looked like it is achievable long-term.

comment:9 Changed 11 years ago by sjmurdoch

Yes, the problem with allowing Tor to continue, when it has been instructed to do change user to the same user,
is that Tor will then retain supplementary groups. This complicates the semantics of the options.

Currently it is "Change to given user, and drop all but primary group"

If we apply the patch it is "Change to the given user, and drop all but the primary group; but if
it is running as that user already, retain the supplementary groups"

I'd be more inclined to either leave it as is, or change Tor to behave the same was as su/sudo --
namely setting the supplementary groups as defined in /etc/group.

FYI, I did test the patch on FreeBSD and OpenBSD and it works as expected.

comment:10 Changed 11 years ago by nickm

Okay. If there's a security issue, then maybe we should improve the error message instead. If the setgroups() fails,
but getuid() gives the same uid as the one we're changing too, we should probably tell people that they want to use
su or User, but not both.

comment:11 Changed 11 years ago by nickm

An improved error message is implemented in trunk; it should be easier to figure out what's wrong for the next
user who runs into this.

comment:12 Changed 11 years ago by nickm

Closing. The next time somebody has an init script that's broken in this way, they'll hear about it from Tor.

comment:13 Changed 11 years ago by nickm

flyspray2trac: bug closed.

comment:14 Changed 7 years ago by nickm

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