[6456] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: Login chroots

daemon@ATHENA.MIT.EDU (Tim Abbott)
Fri Oct 9 13:26:58 2009

Date: Fri, 9 Oct 2009 13:26:50 -0400 (EDT)
From: Tim Abbott <tabbott@MIT.EDU>
To: ghudson@mit.edu
cc: release-team@mit.edu
In-Reply-To: <200910091634.n99GYSR9013990@outgoing.mit.edu>
Message-ID: <alpine.DEB.1.10.0910091312180.18887@dr-wily.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Flag: NO
X-Spam-Score: 0.00

Given the importance of the problem, I think that we need to solve this 
problem in the next month (ideally, much sooner than that).  From seeing 
reactions of students on campus, this probably is probably 10x as 
important as all our other problems combined.

Implementing union mounts and sacrificing #3 results in basically no 
publically facing regressions (people can still install software, etc.) 
and it will fix the speed problem.  I think we can live without #3 in the 
long term; we certainly can live without it for the rest of term.  In 2 
years when btrfs actually works, or when someone figures out how to make 
LVM not incredibly slow (Having previously tried this myself, I consider 
this task quite difficult), we can then re-add feature #3.

I don't think the implementation work for switching to union mounts will 
be very hard because it is so similar to our already well-tested current 
approach (in particular, I think it will actually be less development work 
to achieve acceptable quality and less PR pain than anything that involves 
removing login chroots entirely).

	-Tim Abbott

On Fri, 9 Oct 2009, ghudson@MIT.EDU wrote:

> (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.

home help back first fref pref prev next nref lref last post