From owner-freebsd-hackers Tue Aug 17 22:40:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles542.castles.com [208.214.165.106]) by hub.freebsd.org (Postfix) with ESMTP id 97F05157B9 for ; Tue, 17 Aug 1999 22:40:47 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id WAA00489; Tue, 17 Aug 1999 22:33:51 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199908180533.WAA00489@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: wsanchez@apple.com Cc: 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: Your message of "Tue, 17 Aug 1999 19:17:45 PDT." <199908180217.TAA03970@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Aug 1999 22:33:51 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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: Basically, you have two alternatives; transport the user credentials with the media, or map the credentials on the media to something that's more sensible. In different situations, one or the other of these might make more sense. Throwing some examples: a) You put some files on a removable device. They are "owned" by you. You give the media to someone else, who then mounts it on their own system (which is logically totally disjoint to yours). The desired goal is for the recipient to be able to access the files just as you could. In this case, possession of the media is the desired credential, so the media itself should (ideally) not contain any other credential information (or it should be ignored). b) You move a disk from one server on your network to another. The disk contains files owned by hundreds of users. The desired goal in this case is for the users that could access the files on the first server to be able to access the same files in the same fashion when the disk is on the second server. In this case, the credentials are external to the media and need to be verified against it. One possible way of differentiating these two cases would be to have a flag associated with the media (filesystem perhaps) that indicates whether the media has "security features" enabled. If it doesn't, the media should appear as though everything on it is owned by the user that has mounted it. You would default "security features" off when removable media were initialised. With "security features" on, the media behaviour would be what we consider normal; permissions on files, directories etc. are checked and so forth. The issues related to migrating volumes with "security features" enabled are more interesting; the only atomic way to migrate the credential verification information is to write it to the disk before it's removed. eg. You would offer a "prepare disk for export" option which scanned the disk and wrote out a passwd/group-style database containing the credentials for the uids and gids represented on the volume; this would then need to be integrated into the new system in a suitable fashion, either by merging apparently identical users/groups (and possibly scanning the disk volume to update uid/gid values) into the new system's authentication databases (this would have some perhaps slightly interesting consequences), or by applying the per-volume list as a translation to allow users known to the media to access the system in some suitably limited fashion in order to get at the data on the media. One alternative that would allow migration within a heterogenous network but prevent dealing with the quite complex issues of migrating credentials would simply be to scan every volume with "security features" enabled which didn't appear to have been last used locally and check that all the users represented there were locally valid. This would benefit from having the uid:username and gid:groupname mappings available (maybe it would be faster just to dump the entire database to the disk?) since the scan could fall back to using a network authentication service (NIS, etc.) to obtain the data required to support the users locally. I'm probably being as confusing as you thought you were. Any of this any use? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message