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 -- 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
