Re: Am I way off base here?

[Jan Grant <Jan.Grant@xxxxxxxxxxxxx>]

On Tue, 25 Nov 2003, Matthew Dillon wrote:

>     Is there something fundamentally difficult about implementing
>     things like getpwnam() through an IPC mechanism + maintainng a local
>     cache that I am missing?  Because I am really getting angry at the
>     FreeBSD-5 folk acting so goddamn high and mighty about their NSS DLL
>     requiring a dynamic root crap.
>
>     Sorry, just venting.  But, damn it, it's annoying.  What the hell do they
>     think they are accomplishing other then obfuscating the system even more
>     then it already is?  I mean, we've had the concept of NIS for a long time.
>     It's obvious that IPC is the only way to go for this stuff even though
>     NIS never implemented it right.  What am I missing here?

I had a brief off-list conflab with Jacques (author of the current
implementation) on this. I trust he won't feel that I'm putting words in
his mouth on the subject: the gist of it was -

He _did_ consider out-of-process getpwnam etc: basically, a better
design for NSS than the existing NSS APIs (which are not in the least
bit helpful when it comes to producing a multithreaded getpwnam server,
say). That is, he recognises that doing NSS again from scratch would
mean that tackling a number of thorny issues properly would be possible.

However, the pragmatic pull to maintain current NSS APIs (as found in
Linux and Solaris, for example) is that it means porting an NSS plugin
doesn't involve a ground-up rewrite.

If you try to write an NSS "getpwnam" server using modules written to
the current API, you rapidly come unstuck because the guarantees
required by implementors of a module just aren't strong enough.

The providers of several NSS modules are in various stages of
"rediscovering" the idea of out-of-process servers, to tackle all sorts
of issues (credential visibility, per-invocation costs, resource
management, etc). It's a shame that the work for these winds up being
effectively duplicated rather than managed through a standard
framework/lifecycle enshrined in an NSS++ API, but them's the breaks.

jan

PS. For what it's worth, at least the current NSS implementation leaves
scope for an NSS module that talks to an NSS server implemented in terms
of a better API :-)


-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
Random act of violence against bread: whole pint.
  -- extract from the "Hawk the Slayer" drinking game