On Tue, 5 Oct 1999, Pat Dirks wrote:
> Hi,
>
> I'm the File Systems Tech Lead at Apple in the Mac OS X Core OS group.
> We've been struggling with the question of how best to handle permissions
> on disks that are moved between systems for Mac OS X and Mac OS X Server:
> the problem is that numeric IDs in inodes (or their moral equivalent)
> written on the filesystem on one system don't necessarily map to the same
> user, if they're valid at all, on another system (although they MIGHT).
> With ZIP drives holding appreciable volumes of data and multi-gigabyte
> FireWire drives becoming more common this is an issue that will
> definitely pop up more and more as people carry data with them on
> removable disk filesystems.
I think your best bet to implement something like this is looking
at what mount_msdosfs in FreeBSD does, and possibly using the umapfs
(mount_umap) system for mapping ID's as it sounds pretty close to
what you guys are looking for.
Another interesting idea would be to a utility to 'brand' removable
media, so that a umapfs mapfile can be written to the disk in more
friendly manner.
However, it seems that a lot of this is going towards automation at
guessing what a user wants, rather than allowing him to customize
what he wants.
> As long as the filesystem is "foreign" no owner or group changes
> (chown(2), chgrp(2)) are allowed (the id spaces are very possibly
> mutually meaningless; local name -> id mappings could make no sense to
> the original owner's system). chmod(2) should still work, though.
This is a bit kludgy and goes against POLA, if the ability exists to
change it then it should be allowed unless explicitly disabled, it
would be terribly annoying imo to startup some process or give multiuser
access to a disk then have to shut everything down in order to properly
chown something.
> ADOPTING "FOREIGN" FILESYSTEMS
>
> When a new, never before seen disk is first mounted in the system it's
> treated as "foreign". This can be changed (with "root" permissions) to
> make the filesystem "local". The filesystem's ID is added to the list of
> local filesystems and forever after when the disk is mounted it's treated
> as "local". As part of this "adoption" process the users is prompted to
> choose one of two ways to handle the existing permissions on the disk:
>
> * Retain them as-is (useful for cases where you have external
> reasons to believe
> the numeric user and group IDs on the filesystem are sensible and
> meaningful)
>
> OR
>
> * Overwrite all owner/group information with the reserved ID
> "unknown". This
> leaves the effective permissions unchanged but enables them to be
> changed
> individually. You can chown(2) and chgrp(2) files and directories.
>
> Note that one interesting option might be to provide a one-time-only
> "adoption" which has no permanent effect; when the disk is encountered
> later it is once again "foreign". This might make sense for security
> reasons (if you don't want this disk to become a possible future carrier
> for SetUID binaries)
This is very interesting, as a timesaver to the second option
(overwriting) you could use the timestamp on the file's permissions
to determine if the UID/GIDs are valid (if they are stale old uids,
or new uid's after a chown/chgrp)
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
