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,
Rune