[6452] in Release_7.7_team
Login chroots
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Fri Oct 9 12:34:36 2009
Date: Fri, 9 Oct 2009 12:34:28 -0400 (EDT)
From: ghudson@MIT.EDU
Message-Id: <200910091634.n99GYSR9013990@outgoing.mit.edu>
To: release-team@mit.edu
X-Spam-Flag: NO
X-Spam-Score: 0.00
(Summarizing a zephyr conversation this morning.)
LVM-based login chroots do four things:
1. Reduce the likelihood that a user's login activities will affect
the reusability of the machine.
2. Allow a user's login activities to include becoming root and
mucking around with the system (e.g. adding packages).
3. Allow the system's real root to take package updates without
affecting the user login session.
4. Slow everything down, particularly the process of logging in.
Login chroots have already been disabled on quickstations because of
(4). jdreed wants to consider making login chroots opt-in on cluster
machines (I'm not sure how one would do this, but ignore that for the
moment).
I observed that if we're willing to sacrifice (3) (and we clearly are,
on quickstations), then it becomes substantially easier to implement
login chroots using union mounts (trac #97). Anders noted the
possibility of a user installing a package in the login chroot and
then the updater runs in the real root; files modified in the login
chroot would not see the changes in the real root, while files
unmodified in the login chroot would. That could cause problems for
the dpkg database files in particular.
The 9.4 story for auto-updates is to run them while users are logged
out, and disable logins while updates are running. If we aren't doing
LVM-based login chroots, we should probably implement this instead,
whether or not we do union-based login chroots. Right now
auto-updates could do things like break a user's running Firefox; I
see this occasionally on my stock Ubuntu machine.
