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

Nicolas Williams Nicolas.Williams at wdr.com
Wed Dec 29 21:10:09 GMT 1999


On Wed, Dec 29, 1999 at 01:59:42PM -0800, Jeremy Allison wrote:
> Nicolas Williams wrote:
> 
> > Kerberos has no uid/sid like concept. Kerberos only has names
> > (principals) and domains (realms).
> 
> *Precisely*. Kerberos and DCE use a name based mapping, not
> a number based one.

So you think filesystems should use strings instead of integers to
represent users and groups in file ACLs? Uids, gids, sids, they're all
optimisations.

> > Let's just say that the main benefit of SIDs is that they provide some
> > hierarchy where uids provide none.
> 
> Yes, but remember we are working on POSIX systems. They
> have no hieratrchy of users. Yes that sucks but it isn't
> a job for Samba to fix.
>
> > The idea is to make Samba use that API and for some external agent to
> > provide it.
> 
> I don't really want Samba to use that API. I'd rather
> Samba only know about uid/gids and have the uglyness in
> the mapping done in one place only.

I'm confused. Samba is the fileserver, Samba has to convert uids/gids to
SIDs to emulate NT ACLs to SMB clients. So Samba needs to be able to
convert uids/gids to SIDs at least. The reverse is not necessary unless
you want to support clients adding/removing users/groups from Unix
files' ACLs (where Unix supports ACLs).

Now, I agree that if the only thing Samba needs to do is convert
uids/gids to SIDs then using the fileserver's host SID as the base SID
and algorythmically converting uids/gids to RIDs of that SID works
fine.

> Jeremy.


Nico

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.



More information about the samba-technical mailing list