Security Identifier (SID) to User Identifier (uid) Resolution System

[Luke Kenneth Casson Leighton]

On Tue, 4 Jan 2000, Cole, Timothy D. wrote:

> > -----Original Message-----
> > From:	Luke Kenneth Casson Leighton [SMTP:lkcl at samba.org]
> > Sent:	Tuesday, January 04, 2000 13:57
> > To:	Cole, Timothy D.
> > Cc:	Multiple recipients of list SAMBA-TECHNICAL
> > Subject:	RE: Security Identifier (SID) to User Identifier (uid)
> > Resolution  System
> > 
> > tim, do you want to implement a libsurs.a / libsures.so?  two functions:
> > 
> > CREDS_POSIX
> > {
> > 	union
> > 	{
> > 		gid_t
> > 		uid_t
> > 	}
> > }
> > 
> > CREDS_NT
> > {
> > 	DOM_SID sid;
> > }
> > 
> > int surs_posix2nt(CREDS_NT *nt, CREDS_POSIx *posix)
> > int surs_nt2posix(CREDS_NT *nt, CREDS_POSIx *posix)
> > 
> > a file /etc/surs.conf should contain the "automap" stuff in it.
> > 
> 	Well... maybe I'll take a shot at this on my own time, when I get
> home tonight.  I don't really have time to tackle it at work right now.
> 
> 	One thing, though -- I can't say I'm comfortable with the POSIX
> credentials representation you have here -- gid 202 and uid 202 will by
> necessity map to different SIDs.  posix2nt is going to need some way of
> knowing whether you "mean" the gid or the uid with that value, so it may be
> necessary to add a flag/enum to the POSIX credentials representation to put
> them in their separate "namespaces"...

no, it's not the job of the SURS table to tell whether a SID is a group or
a user id.

if it's sidtoposix, then you know the SID and therefore you're going to
have just called LsaLookupSids or hotherwise know what the type of the SID
is, teherefore you can determine the type of the uid.

if it's posixtosid, then.... argh.  can you guarantee that the uid or gid
is unique?

argh, argh argh - i _specifically_ wanted to avoid this, it makes the
database more complicated.

*sigh*, ok.  i give in.  you will need the "type" field.

i'd still prefer surs_posix2sid, having to set up the tpy+asuid or
type+asgid as required.

one less function is one less function :-)

 
> 	Actually, I think I might be more comfortable with something like:
> 
> 	 #define SURS_MAX_SUBAUTHS 8
> 
> 	 typedef u_int32_t surs_rid;
> 	 typedef u_int8_t surs_id_auth[6];
> 
> 	 typedef struct _surs_sid {
> 	 	u_int8_t revision;
> 	 	u_int8_t num_subauth;
> 	 	surs_id_auth id_auth;
> 		surs_rid sub_auths[SURS_MAX_SUBAUTHS];
> 	 } surs_sid;
> 
> 	 typedef struct _surs_posix_id {
> 	 	enum { SURS_POSIX_UID, SURS_POSIX_GID } type;
> 	 	union {
> 	 		uid_t as_uid;
> 	 		gid_t as_gid;
> 	 	} id;
> 	 } surs_posix_id;
> 
> 	 int surs_sid2posix(surs_posix_id *id, const surs_sid *sid);
> 	 int surs_uid2sid(surs_sid *sid, uid_t uid);
> 	 int surs_gid2sid(surs_sid *sid, gid_t gid);
> 	 const char *surs_strerror(int error);
> 
> 	(This removes its dependancy on the Samba source, and avoids
> Win32-style "silly structs" for parameter passing when converting from POSIX
> to NT ids.  Maybe the latter is somewhat short-sighted, though -- the
> original idea was to treat these as more opaque credentials, but I
> personally feel like that is better left to a higher layer ... what do you
> think?)
> 
> 	Oh, and, uh, LGPL, right? :)
>