DragonFly kernel List (threaded) for 2003-07
Re: dynamic /bin /sbin
Hiten Pandya wrote:
> 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
>> 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. :-)
Not until we have somthing to replace it with :)