[1008] in athena10
Failsafe xterm and breaking out of the chroot
daemon@ATHENA.MIT.EDU (Evan Broder)
Tue Jan 27 19:04:29 2009
Message-ID: <497FA0CF.4020004@mit.edu>
Date: Tue, 27 Jan 2009 19:03:27 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: debathena@mit.edu
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
So most of the issues with the session names in GDM have been dealt
with, but the failsafe xterm is still a problem.
Currently, the failsafe xterm provided by GDM bypasses the Xsession
script, which is the mechanism we're using to lock[1] the user into the
login snapshot chroot.
The most straightforward way to work around this is to reconfigure GDM
to not display the failsafe xterm as a login option, and provide our own
session type that does go through the Xsession script.
The source code still does hardcode that failsafe xterm in to deal with
certain failures, so even if we disable the option at the greeter, it is
still possible that people will find themselves outside of our chroot.
That being said, those cases are most likely to arise in cases of severe
system breakage, and in those cases a user breaking out of the chroot is
probably the least of our worries.
It does raise an interesting point, though: it's currently really hard
to fix problems with cluster machines. debathena-reactivate +
debathena-cluster-login-config do a damn good job of making it really
hard to escape from the login chroots by any sane means.
I think it would be good to figure out some mechanism by which we can
access the master volume when necessary, but I'm not sure how to do it.
Do others have any ideas on how to implement this sanely?
- Evan
[1] Yes, Anders. I know I said "lock" when I really meant "make it not
even remotely hard to get out". Get over it.
