Date: Tue, 5 Oct 1999 17:09:20 -0700 (PDT) From: Alfred Perlstein <bright@wintelcom.net> To: Pat Dirks <pwd@apple.com> Cc: FreeBSD Hackers <FreeBSD-Hackers@FreeBSD.ORG> Subject: Re: Apple's planned appoach to permissions on movable filesystems Message-ID: <Pine.BSF.4.05.9910051658380.6368-100000@fw.wintelcom.net> In-Reply-To: <199910052119.OAA24627@scv1.apple.com>
next in thread | previous 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. > 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 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?Pine.BSF.4.05.9910051658380.6368-100000>