DragonFly kernel List (threaded) for 2003-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: dynamic /bin /sbin
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.
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]