On Sun, Mar 30, 2014 at 10:45:13AM -0400, Theodore Ts'o wrote: > > Actually, Linux uses a 32-bit uid (as do most other Unix systems). > Changing the uid to be 128 bits would break a truly vast number of > programs, so it's not something anyone has been particularly > interested in doing. > > There have been some proposals to add a 128-bit SID to the struct > creds structure, but this would be in addition to the standard unix > uid, but then local file systems would have to be modified so that the > ACL structures could accept 128-bit Windows SID's, and the of course > all of the ACL userspace utilities would have to be modified, etc. > > There is a much simpler way of handling the general issue of dealing > with foreign user naming schemes, which is to have mapping systems > which map things like Kerberos Principals, or Windows SID's, into the > user's Unix uid. Typically enterprises which are unfortunate enough > to have to deal with Windows clients or servers will typically have > LDAP systems that store both a Windows SID and the Unix uid for Unix > systems, and so a user will have their /etc/passwd entry set up with > their Unix uid, and there is need to interop with a Windows CIFS > client, they can use a mapping function to translate back and forth > between the Unix UID and the Windows SID. > > Sometimes there are people who are trying to build Windows CIFS > servers on top of Linux, have wanted to add the SIDs as an additional > entry in the struct creds, and then make all of the other changes in > the rest of the security ecosystem (SELinux, ACL's, etc.) to support > native SID's. I used to think this might be worth the effort, but > these days, with Windows being a bad memory for more and more people, > I'm not so sure. > > Still, if someone wants to submit all of the necessary patches to > various kernel and user space components, it's not impossible. The > problem is that the only real benefit is to the companies who are > trying to sell Windows file servers to enterprises, and the costs get > imposed on many open source developers for many kernel subsystems and > user space utilities, and so getting everyone to accept the required > code maintenance is much more difficult, especially as Windows' market > share is become lower and lower, and so many of us are much happier > now that it's much easier for us to ignore Windows. :-) +1 from me. Ted finally used the same arguments to convince me that named data streams inside files also belong in the same 'bad idea' pile :-). Jeremy. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
