dynamic /bin /sbin

[Jan Grant]

On Sat, 26 Jul 2003, Matthew Dillon wrote:

> :> Bosko Milekic wrote:
> :>
> :> 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/
>
>     I would say we definitely want to keep a fallback mechanism in
>     libc... a simple spwd (e.g. master.passwd) mechanism ought to be
>     sufficient.
>
>     I really hate the idea of using dynamically linked plug-ins for
>     authentication, at least when used with standard applications.
>     I think it's disaster waiting to happen.  It might be reasonable
>     to use plug-ins for a port service based authentication daemon
>     since that is a far more controlled situation.

Ack, if that's not what it sounded like I meant, I apologise. Yeah, a
lookupd is the place to put this. If the lookupd can be configured to
use varying implementations of its SPIs, so much the better: and it's
only lookupd that ought to be dynamically loading them.

There are billions* of reasons why having individual programs
dynamically linking security plugins directly are a bad idea: by and
large, they fall into two areas: resource management (every "ls"
invocation opening a new SSL connection to an LDAP server? I don't think
so) and proper protection of security domains (does your "ls" instance
need read access to your host SSL client cert? Ick.)

Basically, I think libc with fallback mechanism and a lookupd is the
only really sane way to do this, certainly within a Unix paradigm. It
has the advantage (if you so choose to call it) that it doesn't preclude
a static /sbin.

jan

* well, many

-- 
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/
Solution: (n) a watered-down version of something neat.