Security Identifier (SID) to User Identifier (uid) ResolutionSystem

[Leslie M. Barstow III]

On Thu, 30 Dec 1999, Steve Langasek wrote:
> On Fri, 31 Dec 1999, Leslie M. Barstow III wrote:
> > > A getXXXbyYYY() interface is needed that does not hide SIDs.
> > We could put the SID in the GECOS field...

> This would mean appropriating an existing structure with an established
> purpose, and storing *critical* information in it for which it was never
> intended.
> Hmm. Sounds kinda like what MS did with Kerberos. ;)

> This is a very bad hack.  It's fine if individual sites choose to use
> something like this, but it's not the sort of thing that should be
> *recommended* by the Samba team.  There could be all kinds of information that
> the existing Unix infrastructure *requires* be stored in the GECOS field,
> making this a non-option for them (or at least a very painful option).

> And then, imagine what happens if an admin forgets to lock down 'chfn', or any
> of a handful of other utilities that let a user change his/her own GECOS
> entry.  Whoops..

Actually, I was referring to this in terms of winbind only.  Since winbind
would have complete control over all of this, the hack isn't quite as bad
as it seems.  But I agree, it is pretty bad.  I was just suggesting it
because the requirements of retaining SIDs within the current style
framework was requested.

> > > Actually, a generic interface to user credentials (POSIX, NT, whatever)
> > > is needed. This might then generate interest in kernels supporting more
> > > than one type of credential for processes and, eventually, for files.

> > > After all, the use of cred structs in many *nix kernels was done to make
> > > credentials more opaque to various areas of kernel code. Let's further
> > > this trend.

> > This is beyond my time abilities.  If someone wants to champion this, I
> > would welcome it.  The Linux community would either think (a) this is a
> > good hack, or (b) it will slow down the system substantially (arbitrary
> > credentials being looked up almost constantly will not be quick...)

> An interface for returning arbitrary credentials wouldn't necessarily be
> slower than the existing getpwnam().  In fact, the code could be almost
> identical to getpwnam(), as could the structure returned, except that the
> pw_passwd field would be replaced with something more complex.  The only time
> I see a real slow-down occuring is if you start having to look in lots of
> different places to collect all the credentials...

It isn't returning them which I'm worried about, it's doing a comparison
between them and permissions on files.  Comparing arbitrary credentials
pretty much devolves into string comparison, which is slower than
comparing two numbers the size of your current CPU architecture (32/64
bits), unless the strings are limited to that size themselves (giving us
no improvements...).

To use the current example, imagine comparing SIDs as a speed comparison
vs. uid/gids.  This isn't really a major drag (NT gets away with it...),
but it is a small performance hit (your news server will know the
difference, as will real-time apps which do file or device access). Some
people care a lot about that little drop of speed - the company I used to
work for did.  If it is to be accepted, it will need to be mainstream in
at least one or more of: *BSD, Linux, Solaris, etc.  That means everyone
on that system will take the hit.

As far as collection goes, that is already handled by the nsswitch code
(including the nscd cache daemon) - if it's slow, it isn't going to get
much better or worse by changing the credentials scheme itself.  nscd
makes sure network latency (or other problem) doesn't slow down file
access under most circumstances.

--
Leslie M. Barstow III  | http://www.faerealm.com/phoenix
phoenix at faerealm.com   |    Linux and Apple][GS links:    computers/
PGP key at www.pgp.com |    Fight junk e-mail abuse!:     computers/spam/
Wow!  It all fits.     |