>   A group of us at Apple are trying to figure out how to handle  
> situations where a filesystem with "foreign" user ID's are present.   
> The basic problem is that the user experience using Unix semantics  
> are not really pleasant.  I think some examples would help:

Basically, you have two alternatives; transport the user credentials 
with the media, or map the credentials on the media to something that's 
more sensible.

In different situations, one or the other of these might make more 
sense.

Throwing some examples:

a)
You put some files on a removable device.  They are "owned" by you.  
You give the media to someone else, who then mounts it on their own 
system (which is logically totally disjoint to yours).

The desired goal is for the recipient to be able to access the files 
just as you could.  In this case, possession of the media is the 
desired credential, so the media itself should (ideally) not contain 
any other credential information (or it should be ignored).

b)
You move a disk from one server on your network to another.  The disk 
contains files owned by hundreds of users. 

The desired goal in this case is for the users that could access the 
files on the first server to be able to access the same files in the same 
fashion when the disk is on the second server.  In this case, the 
credentials are external to the media and need to be verified against 
it.

One possible way of differentiating these two cases would be to have a
flag associated with the media (filesystem perhaps) that indicates
whether the media has "security features" enabled.  If it doesn't, the
media should appear as though everything on it is owned by the user that
has mounted it.  You would default "security features" off when
removable media were initialised. With "security features" on, the media
behaviour would be what we consider normal; permissions on files,
directories etc. are checked and so forth.

The issues related to migrating volumes with "security features" 
enabled are more interesting; the only atomic way to migrate the 
credential verification information is to write it to the disk before 
it's removed.

eg. You would offer a "prepare disk for export" option which scanned the
disk and wrote out a passwd/group-style database containing the
credentials for the uids and gids represented on the volume; this would
then need to be integrated into the new system in a suitable fashion,
either by merging apparently identical users/groups (and possibly
scanning the disk volume to update uid/gid values) into the new 
system's authentication databases (this would have some perhaps 
slightly interesting consequences), or by applying the per-volume list 
as a translation to allow users known to the media to access the system 
in some suitably limited fashion in order to get at the data on the 
media.

One alternative that would allow migration within a heterogenous 
network but prevent dealing with the quite complex issues of migrating 
credentials would simply be to scan every volume with "security 
features" enabled which didn't appear to have been last used locally 
and check that all the users represented there were locally valid.  
This would benefit from having the uid:username and gid:groupname 
mappings available (maybe it would be faster just to dump the entire 
database to the disk?) since the scan could fall back to using a 
network authentication service (NIS, etc.) to obtain the data required 
to support the users locally.

I'm probably being as confusing as you thought you were.  Any of this 
any use?


-- 
\\  The mind's the standard       \\  Mike Smith
\\  of the man.                   \\  msmith@freebsd.org
\\    -- Joseph Merrick           \\  msmith@cdrom.com