[456] in athena10
Login chroots and interaction with updates
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Wed Aug 20 03:42:57 2008
Date: Wed, 20 Aug 2008 03:42:12 -0400 (EDT)
From: ghudson@MIT.EDU
Message-Id: <200808200742.m7K7gCGU025337@outgoing.mit.edu>
To: athena10@mit.edu
I'm restarting this thread since my planned architecture has changed.
I'm planning to go with Ken Arnold's original idea, which is using
snapshots of the root LVM. The update script will create a snapshot
prior to beginning the update so that we can get in one user login
during an update. After that snapshot is used, further logins will be
blocked until the update completes.
The devil is now in the details of the communication between gdm and
the update script. I believe I have this properly designed. I'm
assuming each of these four snippets is synchronized by grabbing a
global lockfile (/var/run/something.lock).
When an update begins:
* Snapshot the root to login-update.
* Create /var/run/athena-update-in-progress.
When an update ends:
* If login-update still exists, it was never used, so destroy it.
* Clear /etc/nologin if it was created by gdm.
* Remove /var/run/athena-update-in-progress.
When a login begins:
* If an update is in progress, rename login-update to login.
* Otherwise, snapshot the root LVM to create login.
* Mount the login snapshot and add it to schroot.d.
When a login ends:
* Force-unmount the login snapshot and destroy it.
* If an update is in progress and login-update does not exist (which
means we used it up), create /etc/nologin.
I'll reiterate the two main reasons why I think this is worth trying:
1. It lets us punt the public workstation verifier script. The 9.4
verifier isn't very comprehensive and is still a bit of an effort
sinkhole as it is. This will be more comprehensive (though the
host root can still be compromised by a malicious actor) and
should be less up-front effort.
2. It increases the functionality of cluster machines by allowing
users to su and install software without bitrotting the machine.
