From owner-freebsd-hackers Tue Oct 5 18:47:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id CA37715687 for ; Tue, 5 Oct 1999 18:47:06 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 81043 invoked from network); 6 Oct 1999 01:44:57 -0000 Received: from shell-2.enteract.com (dscheidt@207.229.143.41) by pop3-3.enteract.com with SMTP; 6 Oct 1999 01:44:57 -0000 Date: Tue, 5 Oct 1999 20:44:57 -0500 (CDT) From: David Scheidt To: Pat Dirks Cc: FreeBSD Hackers Subject: Re: Apple's planned appoach to permissions on movable filesystems In-Reply-To: <199910052119.OAA24627@scv1.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Oct 1999, Pat Dirks wrote: > 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. What about allowing a mapping of the foreign filesystem IDs to local IDs when the filesystem is adopted. A user might well prepare a filesystem on one machine, and then want to use it permently on this. Something that would allow foreign filesystems with key X get uid 1001 mapped to 6002, and uid 1002 to 4534, everything else goes to unknown. This is easier than having to do chown -R everytime some carries a removable filesystem from home to work, or vice versa. > > 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 would think you want this the default behavior. David Scheidt, waiting till Mac OS X to replace his Quadra 605. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message