On Thu, 2007-11-08 at 14:38 -0500, Alan Cox wrote: > Its a solved problem - I'm not saying its solved in RHEL or for our customerbase > thats a different thing. Ok put this way I can agree, it's vague enough I can attach my meaning of 'solved' :-) > > > 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. Ok I think we are mixing things here, it seem we are mixing the need to uniquely represent identities with the need to authenticate them. Please let's not mix the two, they are connected but separate problems. > > > 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. It's not about it being common or uncommon, it is about the pain when you have to merge 2 or more domains (thin the mess in small shops when you have >10 machines which have never been synchronized). Right now it is a huge pain. If you make mapping the default an make UIDs/GIDs make sense only locally, you are in a position to remove the pain completely. > > 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. Again I am not sure why you are mixing authentication with authorization. Authentication is absolutely necessary, but it is a different problem. Once you are authenticated you need an ID to represent you. I am not advocating the UUID to be a blanket credential by itself. This is solved in the most modern network file systems like CIFS and NFSv4, for others we will still suffer the "trust the whole remote machine" problem, but that is no different from what we have today. > How you do the uid mapping is I think not too important. True, in fact I didn't propose a mechanism, I am trying to find out how well or bad people can receive the message we need something like that first. > 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). Exactly! > 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. Yes, it is not in some complex cases, the worst when networked apps transmit a Posix UID/GID over the network (like NFSv2/3 does), in that case the app need to be changed or you need to go back to use a shared table until the app is fixed. The nice thing is that allowing mapping at the system level does not preclude sharing existing maps at a group/domain level. > Truth be told however what most people want for removable storage is blanket > ownership by themself. Sometimes they do, sometimes they don't. If I have a drive I connect to a multi-user system (maybe a once a week backup drive or something) I want to keep the ownership clean. Clearly, ownership in this case is not meant to protect data when the disk is moved to an untrusted machine, but it is still useful inside a trusted group. Ideally a "portable drive file system" would allow to make "everyone" or even a group owner of a file, a concept that, unfortunately is not allowed by the posix semantics :-( but can be nonetheless made to work with a mapping system probably. Simo. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
