DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: dynamic /bin /sbin


From: Jan Grant <Jan.Grant@xxxxxxxxxxxxx>
Date: Sat, 26 Jul 2003 10:52:40 +0100 (BST)

On Fri, 25 Jul 2003, Richard Coleman wrote:

> Bosko Milekic wrote:
>
> >   FWIW, the nsswitch "problem" doesn't necessarily require you to go to
> >   a dynamically-linked root and this was in fact one of the recent
> >   topics of conversation on some of the freebsd lists.
> >
> >   Personally, I myself prefer the so-called "IPC" approach to doing
> >   nsswitch.  Namely, a daemon which is itself possibly
> >   dynamically-linked and which may do caching, and where the libc code
> >   talks to the daemon and has a local 'fallback' method.
> >
> >   FWIW, some guys at RSU (the russian RSU, Rostov State University)
> >   claim to have some daemon code which puts us on the path towards
> >   exactly the above-described model.  This model does not require a
> >   dynamically-linked root.  I think that OS X does something along those
> >   lines, too.
>
> One of the advantages of this approach is that you can do some
> interesting caching at this level.  The disadvantage is that if this
> daemon dies, your box is dead in the water.  Considering that this
> daemon would get more complicated with time (as you add more methods to
> authenticate), this could be worrisome.  But, either can be made to work.

Do you mean broadening the authentication API, or adding additional
authentication sources?

If the latter: each autentication mechanism is supplied by a
dynamically-linked "plug-in". Getting an nscd or lookupd to partition -
ie, sandbox - unstable plugins is a bit more work, but still doable.

The point about libc containing a "fallback" mechanism is precisely so
that a failure of lookupd won't leave the box _completely_ dead in the
water.


-- 
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/
Semantic rules, OK?




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]