[.....]
> 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).
[.....]
> 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.
[.....]
--
Brian <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<http://www.Awfulhak.org> <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour ! <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
