Date: Wed, 06 Oct 1999 13:23:16 -0600 From: "Darren R. Davis" <drdavis@calderasystems.com> To: Alban Hertroys <dalroi@wit401310.student.utwente.nl> Cc: Pat Dirks <pwd@apple.com>, FreeBSD Hackers <FreeBSD-Hackers@FreeBSD.ORG> Subject: Re: Apple's planned appoach to permissions on movable filesystems Message-ID: <37FBA1A4.CA432540@calderasystems.com> References: <19991006164345.50EDF1DD0@wit401310.student.utwente.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------68F74C16051F3BF9E2CFC271 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alban Hertroys wrote: > 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". > > 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. > > 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... > > -- > Alban Hertroys. > http://wit401310.student.utwente.nl > --- > If I had a sig it would be fun. > The quest for the Holy Sig has begun. > I have not yet a clue, > What will you see next issue? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message Having some experience with the way Iomega handled this, they did this very thing. They generated an ID for the disk. They also would have it be changed every time it was mounted. That way if the ID didn't change from what was expected it was assumed to have not changed. If it ever moved to another system, it was rebranded and was now viewed as changed. Darren --------------68F74C16051F3BF9E2CFC271 Content-Type: text/x-vcard; charset=us-ascii; name="drdavis.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Darren R. Davis Content-Disposition: attachment; filename="drdavis.vcf" begin:vcard n:Davis;Darren tel;fax:801.765.1313 tel;work:801.765.4999 x-mozilla-html:TRUE url:http://www.calderasystems.com org:Caldera Systems, Inc.;Engineering adr:;;240 West Center Street;Orem;UT;84057;USA version:2.1 email;internet:drdavis@calderasystems.com title:Director of Research x-mozilla-cpt:;-5088 fn:Darren Davis end:vcard --------------68F74C16051F3BF9E2CFC271-- 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?37FBA1A4.CA432540>