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.

___ ___  .   .  ___
 \    /  |\  |\ \   
 _\_ /__ |-\ |-\ \__