On Thu, Nov 08, 2007 at 01:53:54PM -0500, Simo Sorce wrote: > Alan, I think we live on diffrent planets then :-) Quite possibly. I make mine one, two, third one out unless we missed one. > I deal with ID mappings problems since ever in the Samba world, and I > rewrote the idmap subsystem twice, please trust me when I say the > problem is *far* from being solved, for anything but ideal cases which > do not exist on real networks. Its a solved problem - I'm not saying its solved in RHEL or for our customerbase thats a different thing. > > This doesn't work anyway - a UUID is intended to avoid collisions, it is > > not intended to be securely unique. > > True, but there is almost no way to get something securely unique, and > anyway that's absolutely not the point. What we need is exactly to > avoiding collisions, not securely unique IDs. You cannot avoid collisions using ids that are defacto publically visible. I will choose to clash with your ID because I'm bad. > > Short of having a DNS like global "phonebook" for UIDs the solvable problem > > is "can I have access to xyz" > > Exactly, but yet you need to represent identity in term of UIDs and GIDs > in the POSIX world, hence why I am slowly advocating for *local* mapping > tables. Network mapping tables simply do not work. They work very well when the authetication domain and the user domain and the set of systems overlap - thats actually not that uncomoon. When they don't you need mapping at that level - be it group or system. > with a way to store mappings on removable drivers when needed. Think > agaion of a USB pen drive formatted ext2, you need at least a file where > you map the UID used on the disk to the identity used (be it an email or > a kerberos principal or whatever you can think of to represent an > identity) and for groups too. That makes a lot of sense for deciding who is who, its absolutely useless for authentication purposes. Having a key which says "please sir I'm root" doesn't solve the trust problem on a network. How you do the uid mapping is I think not too important. You would want to load a table of [disk uid][local uid] into a stacking fs or similar and that can be done by parsing the fs in user space (with a default 'root only' rights set until its parsed and loaded). Its not quite that simple because you need to add new user mappings and know what is free. Thats not a trivial excercise on GFS2 I suspect. Truth be told however what most people want for removable storage is blanket ownership by themself. Alan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
