At 7:17 PM -0700 8/17/99, Wilfredo Sanchez wrote:
>  I think the desired behaviour would be that since this is
>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.

While thinking about this, there's also the question of what access
someone other than Joe would have to those files if they are (say)
ssh-ed into the machine when he attaches the removable media.  Not
important for most home users, but relevant in "MacOS 10 Server"
configurations.  I forget exactly how nextstep did this, but there
were some situations where it didn't work quite the way I wanted
(at the time), and yet I couldn't decide on a clean way it should
be changed so I'd get more of what I wanted...

>  One problem with my proposal (setting security and perhaps other
>implications aside for the moment), is that knowing what media is
>removeable is becoming increasingly difficult.  Hot-swappable drives
>(eg. FireWire) are effectively removeable, and may be transported
>between machines fairly regularly.

Does firewire also allow multiple computers to access a given drive
at the same time (by "same time", I mean "without having to rewire
any hardware").  IBM's SSA disks also have this idea of multiple
hosts for a single disk, even if the hosts consider that disk as
"local"...

>  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
>want to ignore setuid bits, for starters.  This could simply be
>something like fstab, which lists the local drives, and everything
>else isn't considered local.

What happens when that entry isn't made right, though?  To take another
example from NeXTSTEP experience, consider the confusion caused when
people did forget to make a correct fstab entry when they added a hard
disk which WAS considered local and non-removable.  Files were always
owned by whoever logged in, and were actually written to the disk 
with UID=nobody or root (I forget which).  This caused a different 
set of
problems once they realized the mistake, and then put the correct
fstab entry in.  At that point, no one but root had access, since all
the original-creator info was gone.  So, if you do have a marker to
indicate a local drive, what happens when the marker is switched
on<->off?

>  But then the question is, how do we want to deal with non-local
>filesystems?  The ideal thing would be to have a way to transport
>user information with the filesystem (eg. uids on disk are mapped to
>system uids via a per-filesystem database with more global IDs like
>email addresses), but that could be expensive.

Obviously I'm not helping much here...  I have thought about this from
time-to-time (due to my nextstations), and if I think about it enough
I generally end up with a headache and go home.

If considering some database like this, also consider that changing
machines does not necessarily mean different accounting info.  I may
have several different G3's with the exact same accounts, quite
delibrately, so I don't think a "host ID" marker is quite the right
marker.  A school with multiple labs of machines, for instance.  Each
lab might be the exact same id's, with different ids between labs.  If
I bounce around between thirty different machines in one lab, modifying
files on my own little zip disk, it'll be weird to have that listed as
thirty different UID's on the filesystem.  I imagine it is workable, it
just seems weird.

Also note that different machines may deliberately have the same UID's,
even though they are not using the same netinfo server.  My machine at
home vs my machine in the office, for instance.

Some kind of signing/encryption of files (the actual data) might work,
but I'm not sure an average person would want to try to keep track of
the encryption keys (passwords, mappings between them, whatever).

My head is starting to throb.  I think I'll go home...


---
Garance Alistair Drosehn           =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer          or  drosih@rpi.edu
Rensselaer Polytechnic Institute