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.
Fred Sanchez, prompted by some discussions we'd been having on the
subject, posted a query here a while back that prompted quite a bit of
discussion (the "Need some advice regarding portable user IDs" thread).
Based in part on the points advanced here in the earlier discussion,
here's the consensus we've settled on so far. I realize this is a
lengthy message but any comments would be greatly appreciated.
FILESYSTEM PERMISSIONS HANDLING
We considered the idea of writing the system's mapping between IDs and
names on the disk itself. The drawbacks of any scheme like this is that
the disks must be updated constantly (at least potentially with every
chgrp(2) and chown(2) call that could introduce a new ID on the
filesystem, or at best at unmount()) in order to be ready for transport.
The real drawback is that there's not necessarily any correlation between
"Fred" on system "A" and "Fred" on my home system. They might be the
same person or they might not be. Even if I could, mapping "Fred" on the
newly mounted filesystem to the ID of the "Fred" in my /etc/passwd
wouldn't necessarily cause the files to belong to the right person, who
might be "wsanchez" on my system.
Instead we decided to leave all name <-> ID mapping systems unchanged and
rely on a distinction between "local" filesystems whose permissions
information should be used and a "foreign" filesystem mode where owner
and group IDs are ignored.
DISTINGUISHING BETWEEN "LOCAL" and "FOREIGN" FILESYSTEMS
Central to the handling of permissions on filesystems in Mac OS X will be
a 64-bit globally unique ID that will be written onto the filesystem (in
some format-dependent way). How this is derived is a detail to be
addressed and isn't really relevant to this discussion. Some use of an
Ethernet hardware address would be ideal. We considered doing the
reverse (assigning a globally unique ID to every system and "stamping" it
on filesystems that it mounts but that (a) doesn't permit sharing of
media with permissions intact and (b) could be troublesome for read-only
media) so we settled on identifying filesystems instead.
The system will distinguish between "local" and "foreign" filesystems:
"local" filesystem are treated exactly as all volumes are right now while
"foreign" filesystem get special treatment in the form of a uniform set
of permissions that's artificially supplied by the kernel filesystem: the
kernel will ignore the owner and group fields on the device and sustitute
a new special reserved ID for the owner and group that maps to something
like "unknown". Although we plan to support this directly in the kernel
filesystem, it could be enforced through a separate filesystem layer as
well.
The distinction between "local" and "foreign" filesystems is made on the
basis of a filesystem's unique ID. The system maintains a list of
"recognized" filesystem IDs; if a mounted filesystem is on the list it's
treated as "local" and otherwise it's "foreign". There is a process for
changing the system's handling of a filesystem ("adopting" a "foreign"
filesystem, if you will), which may or may not overwrite all the
permissions on the filesystem at the user's discretion. More about that
later.
PERMISSIONS ON "FOREIGN" FILESYSTEMS
In calculating access permissions the user logged in on the console (or
perhaps the user who mounted the filesystem) are granted the permissions
of the "owner" according to the permissions on the disk. This would
allow, for instance, files made deliberately read-only to the original
owner of the disk to remain read-only. This may be a bit odd in cases
where the original owners of two files were different because that
distinction will be lost but on the whole it seemed preferable to
granting the local user the equivalent of "root" access. We also
considered assigning a single set of uniform permissions for every file
and directory on the volume (based, say, on its mount point or an option
on the mount command) but decided that would be unnecessarily inflexible.
Other users in the system are granted whatever "others" permissions are
written on the disk. World-readable files will still be world-readable,
private files will still be private.
Note that this means that if the user who's logged onto the console also
telnets in from another machine they'll get the full owner access,
exactly as the console user is getting. The distinction is based on user
ID, not process (group).
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.
SetUID and SetGID are trusted exactly as they are today, that is, only
when the disk was mounted as root (and only if the volume has been
accepted as "local").
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)
KNOWN PROBLEMS
* Restricting non-console users to the "others" category of permissions
could have surprising effects when someone's umask is set to exclude any
"others" access but they somehow have write permission to a directory:
they'll be able to create new files and directories that they cannot
access in any way. We have no good solution for this problem but it
seems sufficiently rare and hopefully not too surprising for those
enterprising enough to get themselves into this situation.
Any comments or alternative suggestions would be greatly appreciated. If
this is not a scheme you can envision being adopted by the greater *BSD
world, I'd love to hear about it. Thanks for your help!
-Patrick.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
