Date: Wed, 6 Oct 1999 17:11:41 -0700 From: Pat Dirks <pwd@apple.com> To: "Alfred Perlstein" <bright@wintelcom.net> Cc: "FreeBSD Hackers" <FreeBSD-Hackers@freebsd.org> Subject: Re: Apple's planned appoach to permissions on movable filesystems Message-ID: <199910070011.RAA00348@scv2.apple.com>
next in thread | raw e-mail | index | archive | help
>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.
The problem trying to use the umapfs to solve the problem are that
(a) there may be no mapping for some or all of the IDs involved
(b) it presumes maintaining a mapping file ready-to-go when the disk
is
unmounted/removed
(c) the real correspondence between users on the two systems is
really
external knowledge. Even if I could map "Fred" on the source
system
to the id of a "Fred" on the receiving system there's no
guarantee that's
correct.
If there's some way to know that some or all of the IDs on the "foreign"
filesystem are meaningful, possibly after mapping, the system should
"adopt" the drive as "local", preserving the IDs, and then use umapfs the
way it would be on any filesystem. There's no way to do this correctly
without external knowledge, though.
>> 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.
There's no ID that could sensibly be written since the IDs on the
filesystem are from a different ID mapping space so chown() and chgrp()
MUST fail. It's not a matter of defaulting of some option. As for the
POLA, imagine how surprised the original creator of the filesystem would
be to find random user/group IDs assigned to files and directories on the
disk. I would think that seeing "unknown"/"unknown" for the user and
group on every file and directory on the "foreign" filesystem should
reduce the astonishment fact considerably.
>> 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)
That'd be an intriguing optimization. It would require maintaining a
timestamp for every file and directory on the disk to note the time of
the last change, though, in addition to the filesystem's timestamp,
wouldn't it? I suppose you could check that the owner/group IDs are
corrected if the "last changed date" is ever updated and ignore the
owner/group IDs if the last changed date is before the filesystem's
timestamp and thereby incrementally update individual
filesystems/directories on the filesystem without a lengthy delay at
"adoption" time.
Thanks for the feedback!
-Patrick.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910070011.RAA00348>