Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 06 Oct 1999 20:20:04 +0900
From:      "Daniel C. Sobral" <dcs@newsguy.com>
To:        Pat Dirks <pwd@apple.com>
Cc:        FreeBSD Hackers <FreeBSD-Hackers@FreeBSD.ORG>
Subject:   Re: Apple's planned appoach to permissions on movable filesystems
Message-ID:  <37FB3064.14803393@newsguy.com>
References:  <199910052119.OAA24627@scv1.apple.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37FB3064.14803393>