Storing GUIDs in Linux

Storing GUIDs in Linux

[Sankar P]

Hi,

http://en.wikipedia.org/wiki/Globally_unique_identifier is one way to
uniquely identify users. It is used by Active Directory too. The size
of a GUID is 128 bits.

I want to store the GUID of users who creates files, on my
experimental filesystem https://github.com/psankar/simplefs

The size of the "uid" in UNIX is just 16 bits. So what is the way used
by the Linux [filesystems] to store the GUID in linux to uniquely
identify an user ?

Were there any proposals in the past, to increase the size of the unix
uid to match that of a GUID ?

-- 
Sankar P
http://psankar.blogspot.com

Re: Storing GUIDs in Linux

[Theodore Ts'o]

On Thu, Mar 27, 2014 at 09:33:30PM +0530, Sankar P wrote:
> 
> http://en.wikipedia.org/wiki/Globally_unique_identifier is one way to
> uniquely identify users. It is used by Active Directory too. The size
> of a GUID is 128 bits.
> 
> I want to store the GUID of users who creates files, on my
> experimental filesystem https://github.com/psankar/simplefs
> 
> The size of the "uid" in UNIX is just 16 bits. So what is the way used
> by the Linux [filesystems] to store the GUID in linux to uniquely
> identify an user ?
> 
> Were there any proposals in the past, to increase the size of the unix
> uid to match that of a GUID ?

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.  :-)

	       	   	      		  - Ted

Re: Storing GUIDs in Linux

[Jeremy Allison]

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.