From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Allison Subject: Re: Storing GUIDs in Linux Date: Mon, 31 Mar 2014 12:07:36 -0700 Message-ID: <20140331190736.GB24608@samba2> References: <20140330144513.GF7172@thunk.org> Reply-To: Jeremy Allison Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sankar P , linux-fsdevel@vger.kernel.org To: Theodore Ts'o Return-path: Received: from fn.samba.org ([216.83.154.106]:53784 "EHLO mail.samba.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753516AbaCaTHh (ORCPT ); Mon, 31 Mar 2014 15:07:37 -0400 Content-Disposition: inline In-Reply-To: <20140330144513.GF7172@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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.