Security Identifier (SID) to User Identifier (uid) ResolutionSystem

[Luke Kenneth Casson Leighton]

On Thu, 30 Dec 1999, Jeremy Allison wrote:

> Nicolas Williams wrote:
> 
> > The API I proposed is not an NSS API because there is no standard
> > get*by*() Unix API that deals with SIDs. We had a long thread on the XAD
> > list about how it would be nice if *nix kernels (and libc's) had a more
> > generic credential interface. These topics are related :)
> 
> I agree the UNIX kernels need a more generic credential interface.
> 
> I'm not convinced that SIDs or copying NT is the right answer though.
> That's where we differ. I want to look at the problem in isolation
> from NT and try to solve it *right* rather than copying another
> design (which has its own problems).
> 
> > The traditional Unix uid/gid system is inferior to the NT SID system.
> 
> I agree. I just am not convinced that adding SIDs to POSIX is the
> right thing to do. The approach used by Kerberos or DCE may be better.
>  
> > How about something like this:
> > 
> > #define POSIX_USER_CRED 1
> > #define POSIX_GROUP_CRED 2
> > struct posix_cred {
> >         int type;
> >         union guid {
> >                 uid_t uid;
> >                 gid_t gid;
> >         }
> > }

yeah, that's one way.  i was trying to think of something that doesn't
mean i have to store a separate "type" field in database implementations
of SURS.

if you have the SID, you should already know its type.  if you're calling
surs_sid2guid() you should knmow that the SID type is SID_NAME_USER, so
can select guid.uid.

if you have a uid, you do this:
uild.uid = uid;
surs_guidtosid(g, &sid)
and then it would _probably_ be a good idea to do LookupSids(sid) and
check the type retyurned is a SID_NAME_USER, but it's not necessary.

i'm trying to think.  are there any circumstances under which you do not
know the type of a SID, or cannot obtain it?  no, i don't think so.  if
you have a SID, you should always be able to do LsaLookupSids on it.

what about samba-implemnation of a SAM db on which lsalookuipsids is
called?

thought-experiment:

lookupsids(S-1-5-domain1-5000, char* name, sid_name_use *type)

jeremy's pdb_user_rid_to_uid(5000) returns -1, it failed.
pdb_group_rid_to_gid(5000) returns 1293, it succeeded.  excellent, it's a
gid, so we return SID_NAME_GROUP.

of course, we don't _have_ a pdb_alias_rid_to_gid() in samba 2.0.x, so
there's no support for the concept of local aliases in samba.

thought-experiment 2

lsalookupsids(S-1-5-domain1-5000, char *name, sid_enum *type)

hmmm.  we're screwed... i think.

the RID, 5000, is one of our own RIDS. therefore, we control the SAM
database.  the SAM lookup mechanisms.. actaully, that's ok!

yep, we're fine.  i was getting confused for a minute between SURS table
usage and SID-creation/management.  OK, COOL!  we can use the same
mechanism as in thogut-experiment 1, above.

so, yes, you don't need to distinguish between uids and gids, you use
LsaLookupSids to do that.

> > int surs_sid2guid(surs_handle * handle, sid_t sid, posix_cred * pcred);
> > 
> > The int result of the surs_sid2guid() function would be used to indicate
> > success/failure+reason.
> 
> This looks fine for winbind. I just don't want it in Samba.

want is not good enough, unfortunately.

by the same reasons that SURS tables must be used in winbind, pam_ntdom
and pam_smb, if you have your way, samba is going to be the one left out
of the full NT-domain-compatibility picture, and i really don't want that
to happen.

luke