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

[Leslie M. Barstow III]

On Thu, 30 Dec 1999, Nicolas Williams wrote:
> Leslie M. Barstow III (phoenix at faerealm.com) wrote:

> Luke insists that the current behaviour is bad. IT IS NOT. It's just
> looks bad because when one tries to look at and manipulate ACLs on Unix
> files on SMB clients via Samba fileservers one will see user/group names
> that are qualified as being local to the Samba server REGARDLESS of any
> REAL EQUIVALENCY there might actually be between the NT user and it's
> Unix persona.

Actually, I think Jeremy over-simplified when he stated there were no
problems with multiple domains (on which you based this conclusion).  For
your situation, he is right - there is no problem with current
name-mapping.  However, you and I are both thinking about corporate
mergers.  I've already seen name conflicts between domains, and neither
half of the new company wants to change, but they want added access.  The
SIDs work together, but Samba only uses the name, and that doesn't.

> > * winbind: Samba *could* use winbind to do it's uid resolution, but 
> >   needs to pass a full "needs to pass a full "user at domain" name to
> >   ensure proper identification. 
> >   I'm not sure all systems' getpwnam() functions are up to handling long 
> >   names, though. Also, this does not lock out name re-use, and NT 
> >   encourages it by doing all authentication based on SID (not 
> >   name) - Samba has the right info, Winbind wouldn't. Also, Winbind 
> >   should be using a table lookup to prevent confusion in complex 
> >   configurations. 

As a followup: the getpwnam() interface does not specify a string length,
so if it was implemented correctly, it should be fine with long strings.

> A getXXXbyYYY() interface is needed that does not hide SIDs.

We could put the SID in the GECOS field...

> Actually, a generic interface to user credentials (POSIX, NT, whatever)
> is needed. This might then generate interest in kernels supporting more
> than one type of credential for processes and, eventually, for files.

> After all, the use of cred structs in many *nix kernels was done to make
> credentials more opaque to various areas of kernel code. Let's further
> this trend.

This is beyond my time abilities.  If someone wants to champion this, I
would welcome it.  The Linux community would either think (a) this is a
good hack, or (b) it will slow down the system substantially (arbitrary
credentials being looked up almost constantly will not be quick...)
 
> Jeremy wants SURS to be outside the scope of Samba. If that's to be so
> (I second Jeremy on that one, actually), then the issue of maintenance
> of multiple databases that have information in common should ALSO be
> outside the scope of Samba. This is not an uncommon problem, or rocket
> science either.

True (and I agree with Jeremy that the core code is not a core Samba
function, too - I just think it wouldn't be bad to throw it into the
distro (perhaps as a contrib) because it would integrate well and easily
with Samba).

And maintenance really isn't an issue if the programs/libraries using the
interface take the time to maintain the table based on their latest
information.

(e.g. if Samba used it, and a user was returned as deleted, then it
      should make a sid_del() call into the SURS library in addition
      to doing all the optional funky things it currently does.
      Same goes for PAM and winbind.)

PS - how do you folks get through all of these messages?  I could have
     a full-time job just on conversations :-}

--
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.     |