| I suppose you could carry a UID, GID mapping on the disks, and  
have mount look
| out for it.. If you had a 'removable disk' flag in /etc/fstab,  
then have the
| kernel look for those files, and use umapfs with them on the  
mounted FS. It
| could be rather dangerous security wise though.. Maybe have an  
option somewhere
| else (sysctl?) that tells mount wether removable disks are allowed  
to have
| files that are executable/devices/s[ug]id on it. (ie automatically  
have -o
| noexec,nosuid,nodevice done automatically based on user prefs)

  I would assume that unless the user has the appropriate  
priveledges and specifies otherwise, that all non-local media will  
not honor setuid and so on.  So far, I'm thinking of local media as:

	1) The root device, (which holds the kernel, so you have to  
trust it)
	2) Volumes that were initialized locally and have been kept local.
	3) Any devices the administrator has specified as such.

#1 is easy.  #2 implies some way of knowing what's been kept local,  
which is hard.  #3 sounds easy.

  Aside from the setuid business, I might want to toss out any UID  
from non-local media, since they may not be relevant.  On the other  
hand, they might be, and it would be nice if I could keep them in  
that case.  And all of this wants happen without user intervention  
where possible.

  Oh, about fstab... right...  (This is just FYI.)  So we have a  
program called autodiskmount, which at boot time looks for available  
media and mounts it (mount point is determined by the volume label).   
We don't use fstab normally, mostly because we want users to be able  
to attach a drive and not have to configure it; it just shows up  
when they boot.  The Finder does a similar thing:  it gets notified  
when new media is available and it will try to mount it.  The present  
behaviour in Mac OS X Server is that everything mounted this way is  
trusted, though the Finder should be requesting nosetuid; I should  
check that.  It's also possible that the kernel will number drives in  
a different order (eg. /dev/sd0a this boot might be /dev/sd1a next  
boot), particularly if you are shuffling drives around. (Remember  
that hot-swap complicates this.)  So a string like "/dev/sd0a" in  
fstab is fragile, and it works out better if we keep that information  
on the mounted media rather than on the root volume.

	-Fred


--
       Wilfredo Sanchez, wsanchez@apple.com
Apple Computer, Inc., Core Operating Systems / BSD
          Technical Lead, Darwin Project
   1 Infinite Loop, 302-4K, Cupertino, CA 95014