Re: Storing GUIDs in Linux

[Jeremy Allison <jra@samba.org>]

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.