DragonFly kernel List (threaded) for 2003-07
Re: dynamic /bin /sbin
On Sun, Jul 27, 2003 at 11:04:11AM -0700, Matthew Dillon wrote:
> ::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
> ::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.
> I'm going to expand on this a bit.. the reason I think authentication
> plug-ins are a disaster for standard applications is because it creates
> a weak link within the application itself. If you have numerous
> authentication mechanisms one bug could put all of your applications
> (and the environments they run in, some of which might be encrypted
> secure) at risk.
Are we still planning to keep PAM in the base system?
IMHO, we should move out things that are big and unmaintainable
into something like the ports/packages system. This way, they
can be externally managed if possible. Also, maybe at a later
stage in this project's history, a lib-freebsd-compat library
can be supplied for making things like OpenPAM work..
If that is possible, this is just off the top of my head. :-)
Hiten M. Pandya