[6459] in Release_7.7_team
Re: Login chroots
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Fri Oct 9 14:47:59 2009
Date: Fri, 9 Oct 2009 14:47:52 -0400 (EDT)
From: Geoffrey Thomas <geofft@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.0910091430380.13456@dr-wily.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Flag: NO
X-Spam-Score: 0.00
On Fri, 9 Oct 2009, ghudson@MIT.EDU wrote:
> 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.
It is technically possible to use aufs to run updates inside another
snapshot and sync (via the aubrsync script) those changes back to the real
root on login. I haven't looked enough at the code to determine whether
this is a good idea, but it may well be.
aubrsync was written by the aufs developer at the sponsorship of Asus, who
apparently uses this script on the Eee to avoid constant writes to the
more permanent SSD but periodically sync changes to the less permanent
partition.
--
Geoffrey Thomas
geofft@mit.edu
