From owner-freebsd-hackers Wed Aug 18 2:45:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from setec.org (setec.org [205.136.35.171]) by hub.freebsd.org (Postfix) with ESMTP id 232FD14DAB for ; Wed, 18 Aug 1999 02:45:10 -0700 (PDT) (envelope-from izaac@2600.com) Received: from localhost (localhost [[UNIX: localhost]]) by setec.org (8.8.8/8.8.8) with SMTP id FAA26270; Wed, 18 Aug 1999 05:45:27 -0400 (EDT) X-Authentication-Warning: setec.org: izaac owned process doing -bs Date: Wed, 18 Aug 1999 05:45:26 -0400 (EDT) From: Izaac Reply-To: Izaac To: Wilfredo Sanchez 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: <199908180217.TAA03970@scv1.apple.com> 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 Tue, 17 Aug 1999, 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. [...] > 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. [...] > effectively now Joe's zip disk, he should be able to do as he > pleases. One proposal might be to give the console user the > equivalent of root's priveledges on any removeable media he inserts > into the machine while he's logged in on the console. This solves [...] > implications aside for the moment), is that knowing what media is > removeable is becoming increasingly difficult. Hot-swappable drives [...] > So perhaps there needs to be a way to mark a drive as local > (perhaps with a host ID of some sort?) and noticing when a volume is > "foreign" that you need to do something special. Certainly you might [...] This has been tackled by folks distributing via ISO9660+RockRidge.. It's based on a few assumptions: 1) It's data specifically tagged for export. 2) If you're giving it to Other Guy, you obviously want him to be able to read it and navigate it without impediment (otherwise, you wouldn't have put it on there, would you?) 3) Other Guy is responsible for managing his new files. So, let's remove the ROM mentality and apply it to our "removable" media problem: 1) The data may or may not be specifically tagged export. With a ROM, you only decide once what this child of your creativity's purpose will be in life. Is it staying home or going abroad? It would be safe to assume that a very solid majority of users will be neither familiar with mastering nor happy with having the inflexibility of being forced to decide at "Erase Disk..." time (who changed it to that anyway? :P ) whether this volume is local or exported. 2) You'll still want Other Guy to be able to navigate without impediment. The default action would be to save ownership/permission information on media for local use and present a least common denominator view (chown -R 0.0 && chmod -R a=rX) for other recipients. It ought to be transparent, but otherwise able to be manually fiddled with (sometimes you just don't want other people to be able to find out your uname is "fuckwit1"). So yeah, you'll want to tag your media as MINE. A superhappyfun-hash of the hostname and something else ought to make a nice tag. So far as where to put it depends on the FS. Take a looksee at RockRidge's RRIP and SUSP at: ftp://ftp.ymi.com/pub/rockridge/ Or be slicker with UDF at: http://www.osta.org/html/ostatech.html#udf 3) Other guy is still responsible for managing his new files. This can and will get oftly interesting oftly quickly. a) Other Guy goes to mount the media the originator gave him. He checks the superhappyfun-hash ID, which doesn't match his system. The disk is considered alien and goes to LCD mode. One could blindly assume that if Other Guy was able to mount the media (not necessarily be at console) that he ought to own everything on it. Reasonable. b) Other Guy (optionally) has his machine try a little harder to figure out what's actually going on. It could look at the ownership/permissions on the media itself, get a feel for what's what and where, then try to construct a filesystem utopia. This can, in and of itself, get oftly intersting oftly quickly. c) Other Guy (optionally) tweaks things himself. d) From there? He could designate himself the new originator of the media by relabeling the source ID to 'OGsuperhappyfun-hash'. Or, he could store his own o/p map .. locally or maybe on the media itself? He could also remaster the media ("fuckwit2").. Ohh, what a tangled web we do weave ... :) Personally, I like the redesignation.. This could get very expensive, though, for large volumes and/or frequent system swaps (remap, move, remap, move, remap, move, remap.) > As another example, a similar situation often comes up on the net > with tar files containing UIDs and GIDs other than zero. No it doesn't. If you can't chown, touch, or chmod the extracted file to match the archived state, you won't. It's yours with your umask. ___ ___ . . ___ \ / |\ |\ \ _\_ /__ |-\ |-\ \__ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message