[clipping CC list to include @freebsd.org, @netbsd.org, and @apple.com]
>>>>> "Chris" == Chris Dillon <cdil...@wolves.k12.mo.us> writes:
Chris> An origin filesystem (created by and mounted on the same system)
which
Chris> happens to have stuff owned by several different users (this is all
Chris> pseudo... don't mind sizes, dates, and link counts in this example):
Chris> drwxr-xr-x 4 root wheel 512 Aug 18 15:42 ./
Chris> drwxr-x--- 4 harry users 512 Mar 10 10:21 dir1/
Chris> drwxr-xr-x 2 john users 512 Jul 1 18:40 dir2/
Chris> ls -la dir1
Chris> -rw-r----- 1 harry users 0 Aug 18 15:48 bar
Chris> -rw-r----- 1 harry users 0 Aug 18 15:48 foo
Chris> Take this filesystem and mount it as a "foreign" filesystem on
another
Chris> machine. User 'jake' owns the mountpoint on the machine.
Chris> drwxr-xr-x 2 jake users 512 Jan 4 1999 /mnt/
Chris> mount_foreign /dev/whatever /mnt
Chris> ls -la /mnt
Chris> drwxr-xr-x 4 jake users 512 Aug 18 15:42 ./
Chris> drwxr-x--- 4 jake users 512 Mar 10 10:21 dir1/
Chris> drwxr-xr-x 2 jake users 512 Jul 1 18:40 dir2/
Chris> ls -la /mnt/dir1/
Chris> -rw-r----- 1 jake users 0 Aug 18 15:48 bar
Chris> -rw-r----- 1 jake users 0 Aug 18 15:48 foo
Chris> Note file mode bits were not affected, but everything gained the
Chris> user/group of the mountpoint.
I agree up to this point.
Chris> Now what happens if user 'jake' adds something to the filesystem?
Chris> touch /mnt/dir1/baz
Chris> ls -la /mnt/dir1/
Chris> -rw-r----- 1 jake users 0 Aug 18 15:48 bar
Chris> -rw-r----- 1 jake users 0 Aug 18 15:48 foo
Chris> -rw-r----- 1 jake users 0 Aug 18 15:50 baz
>> From jake's perspective, this happens as if it were an origin
Chris> filesystem and he owned everything on it.
Chris> Now, mount the filesystem again on it's origin system.
First, a question: if the disk was mounted by root on the origin system,
then I'm not sure it is safe to mount it again after it has been in another's
hand.
I would suggest that to facilitate cooperation, that the new file should
be made with "jake"'s userid. That may conflict, but I suggest that this
is a higher level issue.
Chris> 1) When writing to a foreign filesystem, should file mode bits
Chris> be inherited from the parent, or be based on the umask of the foreign
Chris> user writing the file at that time? Can the umask of the foreign
Chris> owner be preserved (which isn't necessarily the same thing as
Chris> inheriting from the parent) and used?
I'd say you leave things as is for a file system now.
Chris> 2) How should chown and chgrp act when attempting to modify
Chris> credentials on one of these foreign filesystems? Should it affect
Chris> only the local credential mapping (temporarily) and not modify the
Chris> foreign filesystem? Should you completely ignore the attempts and
I suggest that they fail as non-root can't do chown. If you are root
doing this, then you have no problem, but you don't mount as root.
chgrp continues to function as normal, which may be wrong if groupids
aren't shared, but I suggest that is too, a higher level problem.
Chris> 3) What happens if you want to mount the filesystem on a
Chris> machine besides the origin, but you do NOT want to do credential
Chris> mapping (i.e. the systems both have the same sets of users)? This
Chris> wouldn't matter if you just used a mount option or different
Chris> filesystem type when mounting, but I'm assuming something automagic
is
Chris> wanted here.
You have to mount as root.
Chris> 4) What happens if you change the credentials of the
Chris> mountpoint after you have mounted the foreign filesystem? Should the
Chris> mappings follow the new credentials, or stay as they were when first
Chris> mounted?
It requires some kind of mount/umount operation. It might be as simple as
doing:
"eject floppy"
which will fail because the file system is mounted, but it will then
reexamine the mount point.
:!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease?
Michael Richardson | Cow#2: No. I'm a duck.
Home: <A
HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html";>m...@sandelman.ottawa.on.ca</A>.
PGP key available.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
