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

Luke Kenneth Casson Leighton lkcl at
Tue Jan 4 20:10:38 GMT 2000

On Wed, 5 Jan 2000, Steve Langasek wrote:

> On Wed, 5 Jan 2000, Cole, Timothy D. wrote:
> > 	On another note, although it's not really relevent to Samba, over
> > the holiday I was actually pondering sticking a SURS-like table in a hidden
> > inode on an ext2/3 filesystem, mapping between uids/gids on the disk and
> > SIDs.  The kernel patch would also include a SURS-like mapping table
> > in-kernel, which would map between SIDs and "system" uids/gids (which might
> > well be different from those on disk).
> > 	The kernel table would be filled out from userspace, having a few
> > initial entries for root and the like hard-coded.   SIDs with no kernel
> > entry would map to uid/gid -2 (nobody), until such time as a mapping were
> > added from userspace.  Mapping between fs uids/gids and "system" uids/gids
> > 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?

trust me when i say that mapping to "nobody" is a really bad idea.  this
assumes that the target OS that is using the SURS table is capable of
maintaining the distinction between different users (different SIDs) that
are a lll mapped to the same unix uid.

it's better to set up a series of "nobody" accouts - plural.  nobody1,
nobody2 etc.

More information about the samba-technical mailing list