Make Linux TBB not fail in a non-obvious manner when run as root

Currently, the Linux Tor Browser Bundle tarball contains files owned by a non-root user and its corresponding group. This causes TBB to fail to run when it is unpacked and run by root (Tor sees that its DataDirectory is not owned by the user that it is running as and refuses to run). Regardless of how absurdly bad an idea running TBB as root is, it shouldn't fail in such a non-obvious manner.

There are two not-mutually-exclusive ways to fix this:

1. Set the owner and group of every file/directory in the Linux TBB tarball to root:wheel (UID and GID 0).
2. Add an explicit check to start-tor-browser to detect that TBB is being run as root and refuse to run, with a meaningful error message.

added component::applications/tor bundles/installation owner::erinn priority::medium resolution::fixed status::closed type::defect labels

bsdcpio (shipped with libarchive) can produce tar archives and has a -R option that can set the user and group of every file in the resulting archive.

To make TBB explicitly refuse to run as root, put the following command near the beginning of start-tor-browser.sh:

test "`id -u`" -eq 0 &&
echo "Tor Browser Bundle should not be run as root.  Exiting." >&2 &&
exit 2

The Debian package tardy is another option for removing file UIDs and GIDs from the tarball.

See fixes-2011-08-23-01-master ( https://git.torproject.org/user/rransom/torbrowser.git fixes-2011-08-23-01-master ) for fixes for this bug and some other not-yet-reported issues.

I chose tardy over the other options (GNU tar --owner and --group, bsdtar -R) for removing UIDs and GIDs from the tarball because they seemed less reliable.

Trac:
Status: new to needs_review

Not sure about the last patch, seems it would be yet one more way for TBB to fail to launch without any kind of user feedback when launched from a graphical file manager application?

Replying to Sebastian:

Not sure about the last patch, seems it would be yet one more way for TBB to fail to launch without any kind of user feedback when launched from a graphical file manager application?

I think I've mostly fixed the 'no feedback when launched from a GUI file manager' issue now (on the same branch), along with a few others (including #2525 (closed)).

Now that RelativeLink.sh can display messages to ordinary users, we will also need to figure out how to translate its strings.

I've pushed some UI improvements suggested by velope to the same branch.

This set of changes should be applied to maint-2.2 by running git cherry-pick -x 57bd70de17606df28526ad9524f22f64849f66af..rransom/fixes-2011-08-23-01-master with maint-2.2 checked out. Do not leave out the -x.

Some actual data on what shell-script-GUI programs complain can use:

• The last time I set up a FreeBSD system, the xorg meta-port defaulted to bringing in xmessage. TBB would not be usable on a FreeBSD system with only xorg installed, but it is possible to make TBB run on FreeBSD without installing zenity or gxmessage.
• My default installation of Debian Squeeze from the net-install disk came with both zenity and xmessage, but not gxmessage.
• debian-live-6.0.1-i386-{gnome,lxde,xfce}-desktop.iso have zenity, but not xmessage or gxmessage. debian-live-6.0.1-i386-kde-desktop.iso has none of those three; I'm about to boot it and find out (a) what package kdialog lives in, if it still exists, and (b) how to use it.
• Arch Linux is probably hopeless -- many window manager packages that I remember installing when I was an Arch user didn't pull in any xmessage-like program as a dependency, and the 'desktop environments' seem less popular among Arch users than minimalistic environments based on exotic WMs.
• Gentoo is probably hopeless, too, although xmessage might be commonly installed on Gentoo systems with X.

Can anyone check to see what various default installations/configurations (with X and Gtk installed, of course) of the current versions of Fedora and CentOS include? Are there any other distributions we should care about?

kdialog is in the Debian package kdebase-bin, and I've added support for it to complain.

I've reviewed all of the changes and I like them. One remaining issue: as of Vidalia 0.2.13 (and now Vidalia 0.2.14), and the pending Torbutton 1.4.1, TBB will automatically choose a different port for Vidalia and Tor. Should we remove the checks for Vidalia and polipo, since polipo isn't even in any of the Linux TBBs? If so, do you want to update it? It's a pretty small section of the script so I could do it too, if there is agreement. (I can't see any reason at all to leave it though.)

Replying to erinn:

I've reviewed all of the changes and I like them. One remaining issue: as of Vidalia 0.2.13 (and now Vidalia 0.2.14), and the pending Torbutton 1.4.1, TBB will automatically choose a different port for Vidalia and Tor. Should we remove the checks for Vidalia and polipo, since polipo isn't even in any of the Linux TBBs? If so, do you want to update it? It's a pretty small section of the script so I could do it too, if there is agreement. (I can't see any reason at all to leave it though.)

Erinn removed the check for running tor and vidalia processes; this bug is now fixed.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

closed

mentioned in issue #3076 (moved)

mentioned in issue #3432 (closed)

mentioned in issue #3799 (moved)

mentioned in issue #6597 (closed)

mentioned in issue tpo/community/l10n#3799 (closed)