On Thu, Nov 08, 2007 at 12:54:12PM -0500, Simo Sorce wrote: > The problem being Posix and Linux/UNIX really are not "network-aware" > when it comes to identity. They make certain assumptions about what a uid or gid is, and also about the way they can be manipulated. However that is a *solved* problem. > The UID/GID are *local* by nature. All tricks used up today like NIS and > LDAP to sync UIDs/GIDs all over, are just *bad* hacks. They work, they solve the problem for local users and they make it easy locally to solve the "who owns this" problem, as opposed to the "can I ..." problem. > 1. move to 128bit UID/GIDs that are really UUIDs > problem is, most apps wont work, need changes in the kernel, in a > word: > unachievable This doesn't work anyway - a UUID is intended to avoid collisions, it is not intended to be securely unique. > 2. Make UIDs/GIDs *only* a local thing. > this mean changes in the vfs only, you need a mapping facility so that > you can translate them for (network) file systems. Yes - which unfsd supported in 1994 or so. > I expect preconcept opposition for normal filesystems tho. But that is > needed too, because if you want to use an USB pen drive or external > disk, or even an iSCSI partition you need to be able to map a UUID > stored on the filesystem to the local UID that make sense for the kernel > and all existing applications, or you are back requiring all machines in > the world synchronize with your own machines UIDs and GIDs. For remote access to data you need to stop thinking in terms of "if I say I am number 6 you say yes" and instead move to managing key chains via kerberos and similar systems - exactly as AFS has dealt with the problem and NFSv4 has the framework to handle it. Short of having a DNS like global "phonebook" for UIDs the solvable problem is "can I have access to xyz" Not co-incidentally the kernel has a key management service now, which is ideal for such purposes. Alan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
