From owner-freebsd-hackers Wed Aug 18 15:14:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id E62A11593C for ; Wed, 18 Aug 1999 15:14:50 -0700 (PDT) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.2) with ESMTP id RAA58859; Wed, 18 Aug 1999 17:15:16 -0500 (CDT) (envelope-from cdillon@wolves.k12.mo.us) Date: Wed, 18 Aug 1999 17:15:15 -0500 (CDT) From: Chris Dillon To: Bill Studenmund Cc: "Brian C. Grayson" , wsanchez@apple.com, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, pwd@apple.com, warner.c@apple.com, umeshv@apple.com Subject: Re: Need some advice regarding portable user IDs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 18 Aug 1999, Bill Studenmund wrote: > On Tue, 17 Aug 1999, Brian C. Grayson wrote: > > > On Tue, Aug 17, 1999 at 07:17:45PM -0700, 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. > > > > Have you looked at mount_umap(8)? I (naively) think it would > > solve most of your concerns. > > I don't think so. umap is for translating credentials between domains. I > think what Fred wants to do is different, and that is to ignore the > credentials on the system. > > Fred, right now what happens in MacOS when I take a disk which has sharing > credentials set up, and hook it into another machine? How are the > credentials handled there? > > Also, one of the problems which has been brought up in the thread is that > umap needs to know what credentials to translate to. For that, we'd need > to stash the credentails on the drive. I'm probably being extremely naive myself, but I just envisioned a scenario like this (pardon me if someone else has already suggested this): When a filesystem is mounted as foreign (HOW that is determined I won't talk about), every file in the filesytem has its credentials mapped to that of the mountpoint. File mode bits are not remapped in any way. New files gain the credentials of their _foreign_ parent. That's the skinny. Now I'll give a (much longer) example to clarify. An origin filesystem (created by and mounted on the same system) which happens to have stuff owned by several different users (this is all pseudo... don't mind sizes, dates, and link counts in this example): drwxr-xr-x 4 root wheel 512 Aug 18 15:42 ./ drwxr-x--- 4 harry users 512 Mar 10 10:21 dir1/ drwxr-xr-x 2 john users 512 Jul 1 18:40 dir2/ ls -la dir1 -rw-r----- 1 harry users 0 Aug 18 15:48 bar -rw-r----- 1 harry users 0 Aug 18 15:48 foo Take this filesystem and mount it as a "foreign" filesystem on another machine. User 'jake' owns the mountpoint on the machine. drwxr-xr-x 2 jake users 512 Jan 4 1999 /mnt/ mount_foreign /dev/whatever /mnt ls -la /mnt drwxr-xr-x 4 jake users 512 Aug 18 15:42 ./ drwxr-x--- 4 jake users 512 Mar 10 10:21 dir1/ drwxr-xr-x 2 jake users 512 Jul 1 18:40 dir2/ ls -la /mnt/dir1/ -rw-r----- 1 jake users 0 Aug 18 15:48 bar -rw-r----- 1 jake users 0 Aug 18 15:48 foo Note file mode bits were not affected, but everything gained the user/group of the mountpoint. Now what happens if user 'jake' adds something to the filesystem? touch /mnt/dir1/baz ls -la /mnt/dir1/ -rw-r----- 1 jake users 0 Aug 18 15:48 bar -rw-r----- 1 jake users 0 Aug 18 15:48 foo -rw-r----- 1 jake users 0 Aug 18 15:50 baz From jake's perspective, this happens as if it were an origin filesystem and he owned everything on it. Now, mount the filesystem again on it's origin system. drwxr-xr-x 4 root wheel 512 Aug 18 15:42 ./ drwxr-x--- 4 harry users 512 Mar 10 10:21 dir1/ drwxr-xr-x 2 john users 512 Jul 1 18:40 dir2/ Nothing changed here as far as credentials are concerned. ls -la dir1 -rw-r----- 1 harry users 0 Aug 18 15:48 bar -rw-r----- 1 harry users 0 Aug 18 15:48 foo -rw-r----- 1 harry users 0 Aug 18 15:50 baz The new file added by the foreign user inherited the credentials of its origin parent, just as it would have normally. Points to ponder: 1) When writing to a foreign filesystem, should file mode bits be inherited from the parent, or be based on the umask of the foreign user writing the file at that time? Can the umask of the foreign owner be preserved (which isn't necessarily the same thing as inheriting from the parent) and used? 2) How should chown and chgrp act when attempting to modify credentials on one of these foreign filesystems? Should it affect only the local credential mapping (temporarily) and not modify the foreign filesystem? Should you completely ignore the attempts and not do anything? I vote for temporarily changing credentials (until unmounted), but that is certainly a lot harder to implement than just ignoring the changes. :-) 3) What happens if you want to mount the filesystem on a machine besides the origin, but you do NOT want to do credential mapping (i.e. the systems both have the same sets of users)? This wouldn't matter if you just used a mount option or different filesystem type when mounting, but I'm assuming something automagic is wanted here. 4) What happens if you change the credentials of the mountpoint after you have mounted the foreign filesystem? Should the mappings follow the new credentials, or stay as they were when first mounted? Even if I have no idea what I'm talking about and this was the stupidest idea anyone has ever heard of, I hope that I at least sparked off a few new thought processes and got some more ideas flowing. :-) -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message