Subject: Re: RFC: migration to a fully dynamically linked system
To: None <>
From: Greg A. Woods <>
List: tech-userlevel
Date: 12/21/2001 16:23:18
[ On Friday, December 21, 2001 at 16:20:48 (+0100), Matthias Buelow wrote: ]
> Subject: Re: RFC: migration to a fully dynamically linked system
> I'd greatly appreciate a flexible PAM(-like) scenario, tho..  the
> way authentication is ATM is a bit unsatisfactory, IMHO.  Some kind
> of PAM daemon which is dynamically linked and which organizes
> loading of modules and to which statically linked programs connect
> via IPC would be ok, also... that way static binaries could fallback
> to traditional stuff if the pam daemon is not available (due to
> hosed libraries or whatever.)  That method would be more elegant
> than each program loading the respective modules itself via a
> pam library, even, and is a lot more failsafe.

There are much better solutinos to gain flexible authentication and
authorisation support than to go down the road of pluggable modules.

What exactly do you think you need to dynamically, at run-time in a live
system, change about the way your system does authentication?

Would you not be happy with making a decision about authentication at
install time and sticking to it for the working lifetime of the system?

Yes with proprietary third-party code it might be nice to provide hooks
that can be linked at process start time to a dynamically linked
authentication daemon, but I've never seen any valid justification for
run-time plug-ability, especially not for authentication schemes!

However it's not at all difficult to manage static linking of third
party object modules either.  Third party developers who want to use
fourth party proprietary authentication modules will hopefully be
building their own distributions anyway (I certainly do :-)), and very
little build-system support would be necessary to facilitate integration
of such code.  If I'm not mistaken most of the API is already available
via nsdispatch(3).

								Greg A. Woods

+1 416 218-0098;  <>;  <>;  <>
Planix, Inc. <>; VE3TCP; Secrets of the Weird <>