Date: Wed, 6 Oct 1999 17:22:20 -0700 From: Pat Dirks <pwd@apple.com> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: "FreeBSD Hackers" <FreeBSD-Hackers@freebsd.org> Subject: Re: Apple's planned appoach to permissions on movable filesystems Message-ID: <199910070022.RAA26277@scv3.apple.com>
next in thread | raw e-mail | index | archive | help
>> 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) > >I see a problem with the above. Suppose I receive a disk from a >friend, and then adopt it. I change owners and groups throughout the >fs (chown -R usr:grp is your friend :), and work on it for a while. >Later, _I return the disk to the original owner_. Now, the disk will >be recognized in _his_ computer as being local, when, in fact, it >should be treated as foreign. > >For this reason, I suggest you scrap the fs id if, when making it >local, you opt to replace owners and groups. I'm sorry I didn't mention it in my original post but the plan is that whenever a filesystem is "adopted" and the permissions are overwritten the filesystem's ID is changed to prevent it being recognized as "local" to any systems that previously knew it. If the filesystem's "adopted" while retaining the privileges, the systems that recognize the filesystem as "local" must be able to make sense of the same set of IDs (because they're all from the same source, for instance) and it makes sense to leave the filesystem ID unchanged. It must be possible to have a disk that I can swap between two systems here on the floor when I know there are no conflicting name <-> ID mappings, in which case the two systems must know the filesystem in question by the same filesystem ID. >A problem might still exist where you have a superset of the owners >and groups of whoever lent you the disk. In this case, you might end >up adding owners and groups that do not exist in the system where >the disk came from (and will be returned to). I think this is a >lesser problem, though. It is no worse than uid/gid problems with >NFS. That is indeed a problem, and whoever's deciding how to "adopt" the filesystem had better know what they're getting themselves into. Thanks! -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?199910070022.RAA26277>