dynamic /bin /sbin

[Hiten Pandya]

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
> ::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.
> 
>     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. :-)

	Cheers.
	
-- 
Hiten M. Pandya
hmp at xxxxxxxxxxx, hmp at xxxxxxxx
http://hmp.serverninjas.com/