Kris Kennaway <[EMAIL PROTECTED]> writes:
>Make uids randomly assigned. This solves the problem of collision between
>uids on an introduced medium and the ones on the local system by making it
>statistical (if the uid space is large enough). In order to manage this
>among multiple machines, you'd probably need a synchronisation facility,
>both online (connect to some network database), and by an "export/import"
>facility which lets you dump a DB and import (parts of) it on another
>machine. Storing the large uid in the inode is probably not feasible w/o
>breaking compatability, but you could indirect it through a mapping table
>loaded from elsewhere on disk when the FS is mounted.
>
>The downside to this is not being able to assign the uids according to
>your own numbering scheme. Perhaps what could be done is to have a lookup
>table which maps between in-system uids and on-disk ones, such that the
>kernel presents the translated uid to the system, and remaps the unknown
>ones.
This is a form of the "how do I know who xxxx is?"
Other interesting ideas (some related to the above):
Store on the disk a (small) UID to user-name/identifier mapping. When
mounting a disk, use those mappings to provide the (super)user with
the option to map the UID's of users who match the users of files on
the disk. There are some issues with identifying whether "joe" is the
same "joe" on the other system, but when combined with information
that's currently in passwd, it shouldn't be hard. You can also provide
this info to the person mounting the disk in a nice form that they
can accept, modify, or reject (and mount as totally foreign). For the
case of shared user databases, this should always come up with a
1:1 complete mapping.
You could extend this to use some form of public-key signature to
distinguish between users with similar names, and/or query the original
machine for more info/permission if possible.
When you mount a disk with UID translation going on, you could also
change the UID of new/modified files to be that of the user on the
new system (and update the user database on the partition), so when the
disk was moved back the original owner could filter out modifications
if he so wishes, or 'vet' them. Note: this includes root; or root can
be handled specially.
Much of what's going on here is that the decisions need to be in user
space, and this allows the software to present the user with a likely
set of mappings that they can accept, modify or reject.
If a (non-priviledged) user wants to mount a disk, they should not
be given any other than "other" access to anything (if that(?)), unless
they can identify themselves as the same user as one of the users
on the mounted disk (see above) - depending on how draconian you want
to be, and what level of security you've configured the disk for.
(Note: that last may be an important aspect. When a disk is set up
in a physically somewhat insecure setup (disk outside box, firewire,
etc as is being contemplated) you should be able to decide if you want
the disk to be "movable" or not. (And change that decision later if
you want to move it.)
Please excuse the rambling; I was just throwing out some ideas to see
if any stick to the wall.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
