Security Identifier (SID) to User Identifier (uid) ResolutionSystem
Luke Kenneth Casson Leighton
lkcl at samba.org
Thu Dec 30 06:40:25 GMT 1999
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
More information about the samba-technical
mailing list