[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #12468 [Tor bundles/installation]: TBB unconditionally logs all Firefox output to disk
#12468: TBB unconditionally logs all Firefox output to disk
------------------------------------------+-------------------
Reporter: rransom | Owner: erinn
Type: defect | Status: new
Priority: blocker | Milestone:
Component: Tor bundles/installation | Version:
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
------------------------------------------+-------------------
Comment (by rransom):
Replying to [comment:2 cypherpunks]:
> Some platforms wrongly associates stdout and stderr with a terminal
device. Tor Browser Bundle's startup script broken for them if no terminal
present, stdout leaks out and depends system written to some logs. Like
unity+nautilus.
Which version of Ubuntu are you using? (I can't easily test on Ubuntu
now, but other people will want to know.) Are you using the standard
configuration/state (i.e. default configuration of Unity started from the
default desktop manager, and without running Nautilus from a terminal)?
Which file descriptors are incorrectly reported as terminals?
Are messages that a program sends to stdout displayed to the user
immediately? Are messages that a program sends to stderr displayed to the
user immediately?
Are messages that a program sends to stdout logged to disk, and if so,
where? Are messages that a program sends to stderr logged to disk, and if
so, where?
> Attaching script that detects issue.
{{{
if [ "$ARE_WE_RUNNING_IN_A_TERMINAL" -ne 0 ] && [ '!' -t 0 ]; then
complain "BUG: Wrongly reported as running in terminal"
else
echo "Correct. Running in terminal" >&1
fi
}}}
In the real script, `ARE_WE_RUNNING_IN_A_TERMINAL` only controls whether
`complain` will write its message to stderr or run an X program to display
the message. The security checks are (currently) on lines 139 through
146, and close whichever of stdout or stderr is not a terminal.
It's actually perfectly reasonable for `ARE_WE_RUNNING_IN_A_TERMINAL` to
equal `1` when stdin is not a terminal: for example, if a user types
`./start-tor-browser </dev/null` in a terminal.
`ARE_WE_RUNNING_IN_A_TERMINAL` can also be `1` if e.g. stdout is
redirected to a file, in which case `complain` will still write to stderr.
(This is why the security checks had to be separate from that variable.)
I've attached a script (`list-ttys.sh`) to diagnose the state of a
script's standard FDs more precisely.
It is bad to have `ARE_WE_RUNNING_IN_A_TERMINAL` set to `1` when the user
won't see messages sent to stderr, but that's a user-interface problem,
and not just with TBB. It would be much worse to have stdout attached to
a pty that gets logged to disk, and I can't imagine that anyone would do
that.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12468#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs