Wilfredo Sanchez wrote:
>
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
> The basic problem is that the user experience using Unix semantics
> are not really pleasant. I think some examples would help:
>
> I'm working with Joe on a project, and I have some sources I want
> him to take a look at, so I mount a floppy disk. Well, that's a bad
> example, because floppies are "out"... So I mount a zip disk with UFS
> on it, and I copy my source tree onto it, and hand this to Joe. Joe
> takes the disk home, and sticks it in his computer, and he finds
> that he can't read the files, because I have a lamer umask, and as a
> bonus, I don't have an account on his machine, so the files are owned
> by some random UID.
Having run into this problem myself, both with tar'ed archives and zip
disks I came up with the following dream world one day. In my world there
are two magic uid's, one for a "read only" user and one for a "read write"
user. If I give Joe a zip disk with my files on it all owned by my uid, by
default when he puts it in his drive at his workstation it comes up with
all files owned by the read only user. He can read the files, copy them to
his work station, etc. but he can't make changes to the existing files. If
I want to let Joe change the files on my disk I can set the rw flag, so
when he pops it in his drive it comes up owned by the "read write" user.
(Still assuming that Joe and I have mismatched uid's.)
In a system like this I'd also like to see a flag that lets the owner
require that the uid semantics are enforced. Also, the flags should be
settable on the file, directory and disk levels. Finally in an
ultra-paranoid environment you could set an option that requires that the
uid matchup is for the actual person, similar to the way an ssh public
key/private key pair works.
Hope this is useful,
Doug
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
