From owner-freebsd-hackers Tue Aug 17 22:14:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id DFC7214D8B for ; Tue, 17 Aug 1999 22:14:54 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id BAA19078; Wed, 18 Aug 1999 01:14:23 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <199908180217.TAA03970@scv1.apple.com> References: <199908180217.TAA03970@scv1.apple.com> Date: Wed, 18 Aug 1999 01:14:41 -0400 To: wsanchez@apple.com, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org From: Garance A Drosihn Subject: Re: Need some advice regarding portable user IDs Cc: pwd@apple.com, warner.c@apple.com, umeshv@apple.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message