From owner-freebsd-hackers Wed Oct 6 4:59:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id D4C551512F for ; Wed, 6 Oct 1999 04:59:34 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p20-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.149]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id UAA03060; Wed, 6 Oct 1999 20:58:15 +0900 (JST) Message-ID: <37FB3064.14803393@newsguy.com> Date: Wed, 06 Oct 1999 20:20:04 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Pat Dirks Cc: FreeBSD Hackers Subject: Re: Apple's planned appoach to permissions on movable filesystems References: <199910052119.OAA24627@scv1.apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Pat Dirks wrote: > > 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. 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. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "I always feel generous when I'm in the inner circle of a conspiracy to subvert the world order and, with a small group of allies, just defeated an alien invasion. Maybe I should value myself a little more?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message