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

[Cole, Timothy D.]

> -----Original Message-----
> From:	Steve Langasek [SMTP:vorlon at netexpress.net]
> Sent:	Tuesday, January 04, 2000 21:12
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	RE: Security Identifier (SID) to User Identifier (uid)
> Resolution  System
> 
> On Wed, 5 Jan 2000, Luke Kenneth Casson Leighton wrote:
> 
> > hum, don't know exactly what's going on, here.  like i keep mentioning,
> > i'm not a unix expert.
> 
> > as long as you're not telling me that you want to use nobody(-2) as an
> NT
> > user, i think that's ok, but i don't quite get why.
> 
> > ... how does not mapping to a uid make a user "appear" to have rwx/
> > acccess?  what kind of acess?  and are you referring to "user
> "appearing""
> > as an nt user or a unix user?
> 
> A Unix user.  So far, we're talking about stuff that's internal to the
> Linux
> kernel, so NT users don't enter into the equation.
> 
> Timothy could probably explain better, since he's the one talking about
> writing this driver, but if I understand correctly, ACL's based on SIDs
> would
> be stored on the ext2/3 filesystem, and the kernel would have an internal
> table for mapping these SID's to uid's or gid's.
> 
	Eh, almost.  It wouldn't be ACLs, per se, just another similar
table, that would be stored in a hidden inode.  So the mapping goes
something like:

	 uid/gid <-> SID <-> uid/gid
	 |___________| |___________|
	       |             |
	 kernel table   filesystem table

	ACLs and everything else in the kernel and on the filesystem
continues to use uids and gids.  The SIDs are used only to translate between
"disk uid/gids" and "kernel uid/gids".

	Actually it wouldn't even need to be SIDs for the particular
intermediate representation (they admittedly aren't my favorite), except it
just happened to be a particularly convenient one for a lot of things (a
read/write NTFS driver could certainly take advantage of it, too, not to
mention a SURS module...).

>   An application making calls
> to the Linux kernel via the POSIX API would be given the uid/gid in
> response
> to a query about a file, and this uid/gid would be nobody(-2) if the SID
> can't
> be mapped to any other user/group.  /However/, there would be no inverse
> mapping of the POSIX nobody, so a setuid() call to 'nobody' would not
> suddenly
> grant the application access to these unclaimed resources.
> 
	Yes, that's the general idea.  Root (well, any process with the
apropriate capability mask) should probably still have access to the
resources, though.

	Actually, now that I think about it, you could probably get away
with this even if nobody DID have a mapping (which I suspect it may
sometimes have).  stat() and access control are handled separately, I
believe (it's been a while since I've looked at the relevent code), so you
should be able to return whatever you like in stat() and not influence
access control.

	So, yes, Luke's right -- the mapping function should just fail.
However, if it does, stat() should return some bogus uid/gid as determined
by the mount options (defaulting to uid/gid -2), rather than returning
failure itself.