[6460] in Release_7.7_team

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

Re: Login chroots

daemon@ATHENA.MIT.EDU (Anders Kaseorg)
Fri Oct 9 15:05:32 2009

Date: Fri, 9 Oct 2009 15:05:23 -0400 (EDT)
From: Anders Kaseorg <andersk@MIT.EDU>
To: Geoffrey Thomas <geofft@mit.edu>
cc: ghudson@mit.edu, release-team@mit.edu
In-Reply-To: <alpine.DEB.1.10.0910091430380.13456@dr-wily.mit.edu>
Message-ID: <alpine.DEB.2.00.0910091451120.8245@dr-wily.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8
X-Spam-Flag: NO
X-Spam-Score: 0.00
Content-Transfer-Encoding: 8bit

On Fri, 9 Oct 2009, Geoffrey Thomas wrote:
> 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.

Running updates inside a temporary snapshot could do all sorts of bad 
things like restart daemons inside the snapshot.

If you were going to design a concurrent update system like this, you’d 
want the entire running system to be a snapshot of the root taken at boot 
time.  To make a login snapshot, you aurbsync the boot snapshot back to 
the root, then make the login snapshot from the root.  (You’d also 
aurbsync the boot snapshot back to the root on shutdown.)  Then updates to 
the boot snapshot don’t interfere with login, and daemons are always 
started and restarted in the same boot snapshot.

However, I think this is too much work to think about right now, and we 
should move ahead with aufs without concurrent updates as soon as 


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