Security Identifier (SID) to User Identifier (uid) Resolution
System
Luke Kenneth Casson Leighton
lkcl at samba.org
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