(Illustration by Gaich Muramatsu)
On Sat, Mar 24, 2007 at 11:07:29PM -0700, Adam Megacz wrote: > A possible solution is to synthesize a new UNIX UID for each login > shell (could probably be done in a PAM session module) and reclaim > them when the user logs out. If the only publicly writable space on > local disk is /tmp, this should be easy to clean up after. Hi Adam, your idea is actually very sane. It does not really address the network identity switching issue, but is indeed a natural solution for users with homedirs on "real" i.e. local-uid-independent network file systems. You do not even have to reclaim uids, they can stay "cached" in the generated passwd in case the same name is used again to login, making the setup robust and fully compatible with the traditional semantics. As soon as the installation does not depend on NFS or other uid-centered services, this is a straightforward solution. If you on the other hand really mean using different uids for different logins with the same name, that would disallow sharing between your sessions, which can be frustrating. Each session would have to either use a separate file area, with a corresponding separate network identity, or use the same file area, breaking the isolation between the sessions which was the point. You'd lose also the ability to login separately to trace a hanged process of yours... With other words, the user must in any case make an explicit decision about either isolating or not, and take the consequences. In most cases it seems to be easier to draw the default isolation border between different login names than different login sessions. I am usually content to share files with my previous/parallel sessions. Of course uids-on-demand-setup implies an authentication service, checking validity of claims to represent an account with certain name. Then you need also login authorization, a list of login names allowed to login on a given host. This can be even a simple text file on a (secure) global file system. Then a pam_listfile together with a quite simple pam module appending to /etc/passwd on demand would make it compatible with the rest of a typical *nix system. Concerning authorization with possible help of Coda: Note that a host wishing to use pam_list with a file on Coda _must_ verify the Coda servers' identity, either by having a shared secret with the realm (one secret per host, can be hard to maintain on bigger setups) or by fetching an "anonymous" token with help of public key server authentication (that needs the modular clog and stunnel). That should be done for the uid which runs pam and has a possibility to modify /etc/passwd, most probably uid 0. Concerning authentication with possible help of Coda: To make authentication to be able to rely on Coda password databse, one would need a (hypothetical) service at the realm that can verify tokens over an authenticated connection established with another token (say, anonymous one obtained as above) or over a public-key authenticated connection. Then the client could be sure the server is not spoofed. Regards, RuneReceived on 2007-03-25 05:10:20