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

[Cole, Timothy D.]

> -----Original Message-----
> From:	Luke Kenneth Casson Leighton [SMTP:lkcl at samba.org]
> Sent:	Tuesday, January 04, 2000 15:13
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	RE: Security Identifier (SID) to User Identifier (uid)
> Resolution  System
> 
> 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.
> 
	Well, I said what I did under the assumption that there would be no
mapping from -2 back to any SID (i.e. the mapping function would fail).
Under most systems, no user is ever supposed to be able to become the nobody
user (some kernels (i.e. HP-UX) have a hard-coded limit preventing you from
suiding to uid -2), so that's not really an issue.

	The only reason for mapping to nobody is that it has to map to
SOMETHING as far as POSIX is concerned.  If you stat() such an object, and
you simply have no mapping for it's SID to fill out the st_uid field with,
it's basically a choice of either root or nobody.  Nobody really does mean
nobody, so it really oughtn't map back to an SID at all.

	I don't think creating a mapping on-the-fly is appropriate in the
kernel, because that's heavily a policy decision (i.e. some range of uids
must be allocated, etcetera).  Now, the one sticky bit (no pun) is what you
do if you have a whole slew of SIDs on the disk that aren't otherwise
already known to your system -- I don't know quite what do do about that
case.  I'd tend to think you'd have a similar situation on an NT box,
though.