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

[Nicolas Williams]

[NOTE: I don't subscribe to any Samba list. I read the Samba list
archives. I wish the archive web site would include message IDs so I can
set the In-Reply-To mail header when I reply to mails from the Samba
list so I don't break mail threading].



> <INTRO>I had the pleasure of hearing Jeremy speak a couple of weeks ago at 
> the Denver SGI Linux U., and he talked about wanting an SMB nsswitch. I 
> had indicated an interest in working on it, given some time to get a new 
> PC capable of compiling "Hello, World" in under an hour :-( - I have it, 
> and am still interested.</INTRO> 
> 
> Having said that, the current discussion should be expanded just a little 
> to include an nsswitch module (winbind). Nico's proposed API to Luke's 
> proposal is a good start on what winbind will need (although winbind will 
> then have to take the results and do NT resolution on it, and then 
> mangle the results a bit...). 

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 :)

> Re: the local vs. remote user discussion, Luke is right. According to NT, 
> these are different users, and we have to emulate the NT function, not 
> its POSIX non-equivalent. Local or remote makes no difference. If you 
> have two local users named doej on the same system (don't ask, I've seen 
> it done - NT rules again ;^} ), they are still different, because they 
> have different SIDs. Additionally, a user in DOM1 can be trusted in DOM2 
> (of which the Samba server is a member), and his RID can be the same as a 
> different user's RID in DOM2; the user should have different permissions 
> than his RID-lookalike in DOM2, so a RID-to-UID mapping is not possible. 
> So, the mapping *has* to be one-to-one reversible across the entire SID 
> mapping (wave goodbye to your UID pool...). 

Well, you must have valid uid/gif->SID mappings for all the uids/gids
you care about and those mappings must be reversible, but there is no
need to have to be able to map every SID to a uid/gid (unknown SIDs
could be mapped to 'nobody' and 'nogroup' or some other Unix users with
similar purposes).

Also, I'm talikng about mapping uids/gids to a domain SID+RID; you need
SURS databases for this. Mapping uids/gids to a host SID+RID is what
Samba fileservers do now and works fine (it just looks weird when you
know that a given uid is not a user local to that Samba fileserver but
is the same entity across a whole bunch of *nix systems in your
"domain").

The traditional Unix uid/gid system is inferior to the NT SID system.

This means that there are some restrictions we have to live with. Or
POSIX could be extended to have a more generic interface to process
credentials so it can support more than one type of credentials, then
filesystems could be extended in similar ways and Samba could be made
aware of it all. But I digress.

> And I think that Samba *is* the place to do it. Not all systems support 
> nsswitch, but Samba should be able to work without it. Otherwise you get 
> greatly reduced compatability in Samba, and wind up having to maintain the 
> winbind code with Samba anyway... (And Samba doesn't need all of 
> the functionality of winbind, only the UID/GID<->SID map - full names 
> and shell aren't used, and an NT-shared home directory isn't something we 
> want to re-share :-) 

You're right about Samba needing something less than a full winbind (aka
NSS_AD, aka NSS_LDAP?) implementation.

> Re: the sid2*() call: I think the unified call proposed by Luke is more 
> appropriate than Nico's - you really can't tell in an ACL if the SID 
> refers to a group or to a user (or a machine). Having to code two calls 
> is more of a pain for developers in the long run. 

Right.

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;
	}
}

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.

> ==== 
> 
> On to commentary on the SURS draft: 
> 
> Consider that the database on the other end of getpw*() might be winbind. 
> Assuming that winbind uses SURS code, a recursion would then be set up if 
> SURS automatically went to getpw*() to resolve an unknown SID to a UID; a 
> good SURS implementation should therefore be able to act as an 
> authoritative source of UIDs if configured as such. The Samba 
> implementation should also probably have an option to link into the 
> account creation/deletion hooks in Samba. 

If we're talking about Samba as a fileserver, then the SURS database
could just be ActiveDirectory (or XAD, or whatever else will do).

If we're talking about Samba as a PDC then either the SURS db will have
to be implemented internally to Samba _or_ any SAM write operations
would have to be externalized the same way that I'm proposing
uid/gid<->sid mappings be externalized.

> --
> Leslie M. Barstow III  | http://www.faerealm.com/phoenix
> phoenix at faerealm.com   |    Linux and Apple][GS links:    computers/
> PGP key at www.pgp.com |    Fight junk e-mail abuse!:     computers/spam/
> Wow!  It all fits.     |


Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.