[6456] in Release_7.7_team
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.
>
