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

[Cole, Timothy D.]

> -----Original Message-----
> From:	Luke Kenneth Casson Leighton [SMTP:lkcl at samba.org]
> Sent:	Tuesday, January 04, 2000 14:57
> To:	Cole, Timothy D.
> Cc:	Multiple recipients of list SAMBA-TECHNICAL; 'tcole at bitsmart.com'
> Subject:	RE: Security Identifier (SID) to User Identifier (uid)
> Resolution  System
> 
> 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 :-)
> 
	Ehh, yes, but observe the following:

	 {
	 	surs_posix_id posix_id;
	 	surs_sid sid;
	 	int error;

	 	id.type = SURS_POSIX_UID;
	 	id.id.as_uid = getuid();

	 	error = surs_posix2sid(&sid, &posix_id);
	 	/* ... etc ... */
	 }

	versus:

	 {
	 	surs_sid sid;
	   int error;

	   error = surs_uid2sid(&sid, getuid());
	 	/* ... etc ... */
	 }

	Which API would you rather code to, and which is more readable?

	(This is one of the reasons why I try to avoid Win32-style "silly
structs" in APIs when I can -- the more primitive your parameters, the less
chance you'll have to keep reformatting the data to fit yet another
intermediate structure that you also have to devote extra data/stack space
to)

	If you really expect to work directly with a lot of surs_posix_ids
(not differentiating between users and groups), rather than uids and gids,
then maybe surs_posix2sid would make sense, but I don't think I'd want to
throw out uid2sid and gid2sid even then.  Actually, if macro side-effects
don't bother you...

	 #define surs_posix2sid(sid, posix_id) ( ( (posix_id)->type ==
SURS_POSIX_UID )   \
	                                       ? surs_uid2sid(sid,
(posix_id)->id.as_uid) \
	                                       : surs_gid2sid(sid,
(posix_id)->id.as_gid) )

	(note that it would be nowhere as easy to (portably) define
surs_uid2sid() and surs_gid2sid() as macros in terms of a surs_posix2sid())

	Actally, there's another rationale at work here, too... regardless
of how the actual table is stored (I imagine in practice it'd be one, or at
most two, tables), there are really three "logical" tables:

	 1. sid -> posix uid/gid
	 2. uid -> sid
	 3. gid -> sid

	Conceviably, something akin do the above macro definition for
surs_posix2sid() might have to happen internally anyway, were
surs_posix2sid() to be implemented as a full-fledged entry API call.  Not
that those sorts of micro-optimizations are really important here.

	* sigh *

	Sorry, I have a penchant for turning even the most trivial things
into ridiculously long discussions... :/