Date: Wed, 6 Oct 1999 17:31:19 -0700 From: Pat Dirks <pwd@apple.com> To: "Alban Hertroys" <dalroi@wit401310.student.utwente.nl> Cc: "FreeBSD Hackers" <FreeBSD-Hackers@freebsd.org> Subject: Re: Apple's planned appoach to permissions on movable filesystems Message-ID: <199910070031.RAA27406@scv3.apple.com>
next in thread | raw e-mail | index | archive | help
>On 5 Oct, Pat Dirks wrote: > >Sorry if I'm talking nonsense or if somebody else already pointed this >out, i usually just lurk around this list, but if I'm right I think it >is of sufficient significance... > >> 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: > >Adding the filesystem to the systems list of local filesystems is not >going to guarantee that the filesystem is local at all. If you move a >disk from machine A to machine B, both machines will know the disk with >that ID to be local. Moving the disk back to machine A will cause it to >accept a filesystem as "local" that is actually "foreign". That's not a bug, that's a feature :-) Seriously, if a filesystem, created on system A, is "adopted" on system B with the option of retaining the existing IDs because they make sense on system B, with or without further manipulation through umapfs, it strikes me as DESIRABLE that newly created files and directories, tagged with IDs on system B, should show up as-is back on system A. I neglected to spell out in my original post that "adopting" a filesystem with the option of overwriting all permissions also changes the filesystem's ID and will prevent it from being recognized as "local" back on system A. >The "solution" would be to remove it's ID from the list when the >filesystem is removed from the system, but AFAIK the only way to detect >that is the "umount" that is required to do such. However, an umount >is not enough reason to unmark a filesystem as "local"; it also >happens at reboot, to name just one of the many occurances of umount. >As may become obvious, I'm not an expert at this at all. Perhaps the default behavior should be to accept a filesystem as local once only, requiring a special option to elect to treat the filesystem as "local" whenever it appears. Permanently connected local hard disks should be permanently recognized as "local", of course. >I would rather brand the filesystem with the ID of the host. The >starting situation is an "unmarked" filesystem. If a host detects the >mounting of an "unmarked" filesystem, it will brand it with it's ID. If >it detects a filesystem that has an ID that differs from the host's ID, >it is a foreign filesystem. Seems quite simple to me... The problem with that is that you cannot create filesystems that can be "local" on more than one system, even though there might be a large group of systems that share a common name <-> ID mapping (NetInfo, NIS, LDAP, Kerberos, whatever). It also makes it impossible to create read-only volumes that are "local" on any system other than the creating system. I'm missing the advantage here. If filesystems are created with a unique ID that's entered into the local system's list of "local" filesystems, wouldn't the basic behavior be the same? Systems that don't recognize a newly mounted filesystem's ID will still default to treating it as "foreign" automatically. What's gained by branding filesystems with the ID of a SINGLE "owning" system? 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?199910070031.RAA27406>