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

Luke Kenneth Casson Leighton lkcl at
Wed Jan 5 01:10:02 GMT 2000

> > > would be done by the filesystem driver, so none of the existing
> > interfaces
> > > would really have to change -- no hits from comparing SIDs everywhere,
> > it's
> > > still all word-size integers.
> > 
> > Intriguing.  It's probably not that important for a first implementation,
> > but
> > would it be possible to make the default 'nobody' SID mapping configurable
> > via
> > a mount option?
> > 
> 	Hmm, that's a good idea.  Yes, I would think it'd be trivial to do.
> 	The actual kernel table lookup (which would be independent of the
> filesystems) would still return -2, but since the fs driver would be the one
> doing the lookup, it could return whatever uid/gid it wanted in that case.
> 	Or, better, the lookup function could take a parameter for the
> uid/gid to fall back on, which would of course be supplied by the caller,
> normally fs driver.  Yes, that seems like a better design to me.

tim, trust me on this: as a first implementation, don't do it.  you will
force the users of the surs table to maintain _both_ unix _and_ nt
security context, as you no longer have one-to-one mappings between uid
and sid, and gid and sid.

 if you come across a uid (mapped to nobody), which SID are you going to
map it to?  which of the _many_ potential nt users (or groups)?

if you _must_ provide this functionality, i recomment that you set it up
as an init_surs_table() option, which i would also recommend be the next
version (or preferably not at all).  there are other ways round this
problem that are more controlled.

More information about the samba-technical mailing list