>[.....]
>> Instead we decided to leave all name <-> ID mapping systems unchanged and
>> rely on a distinction between "local" filesystems whose permissions
>> information should be used and a "foreign" filesystem mode where owner
>> and group IDs are ignored.
>[.....]
>
>I think the owner and group of the person that mounted the filesystem
>should be assigned to all files on that filesystem in FOREIGN mode.
>-u and -g switches should be permitted to modify these, the -u being
>restricted to root and the -g restricted to root or one of the groups
>to which you are a member.
>
>This assumes the BSD style I-must-have-permission-to-read-and-write-
>the-raw-partitiion style filesystem mounting by users. It would have
>horrendous implications with the linux-style fstab-says-anyone-can-
>mount-this idea. But then, you already mention this later on :-]
>
>The filesystem code would also mask all suid bits and ignore all
>char/device files on FOREIGN media (as you've already said too).
What do you see as the advantage of explicitly assigning ownership to the
mounting user/group? The effect should be the same in either case? I
suppose it allows an intereting middle-level of access to the group in
question?
In the case of Mac OS X we've got a daemon in the system looking for new
disks being inserted/attached and doing the mount. We still want the
console user to have "ownership" of the filesystem in "foreign" mode.
>[.....]
>> media) so we settled on identifying filesystems instead.
>
>I don't think it's a good idea to be able to identify the filesystem
>as being your own. It's too easy to introduce security problems that
>way. I'd suggest a default of FOREIGN and a root-only mount option
>for LOCAL - ie, root decides, nothing's automated.
>
>[.....]
>> As long as the filesystem is "foreign" no owner or group changes
>> (chown(2), chgrp(2)) are allowed (the id spaces are very possibly
>> mutually meaningless; local name -> id mappings could make no sense to
>> the original owner's system). chmod(2) should still work, though.
>
>And what uid/gid do new files get.... I can't say I like the idea of
>a magic ``nobody'' uid/gid.
Sorry, I neglected to specify that in my original post. Given the scheme
outline in my original post, the plan is precisely to make new files or
directories be owned by "nobody". There's no sensible ID that you can
write onto the filesystem and it makes it easier for the original owner
to track down new files or directories created on the other system.
Thanks,
-Patrick.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
