In article <20050308125255.GG2279@mewburn.net>,
Luke Mewburn  <lukem@NetBSD.org> wrote:
>-=-=-=-=-=-
>
>On Tue, Mar 08, 2005 at 01:44:35PM +0100, Quentin Garnier wrote:
>  | Speaking of which, there is an issue for people like me who compile with
>  | MKKERBEROS=no.  That way, pam_krb5.so is not built, but yet it is referenced
>  | by the pam configuration files.  Hence after the installation of such a
>  | system, I can't login.
>  | 
>  | The solution would be to conditionally comment a few bits of the pam
>  | configuration file.  Do we want that?  I don't think it would be too
>  | difficult.
>
>Why not just modify them in your own source tree?
>Also, once installed the /etc/pam.d files don't get updated by
>postinstall (or etcupdate), so it's a "fix once locally" issue.
>
>I currently don't see the major benefit in providing different
>end-user configuration files based on MK<var> variable settings.
>
I agree... Here's a couple of options:

       1. make all the modules that are optional, to install copies
          of pam_deny.so this way we don't need to fix the sets, or
          hack openpam.
       2. hack openpam to add another keyword "elective" or "discretionary"
          so that the chain does not fail if the file is not found and fix
          the sets. The meaning of "elective" would be "sufficient" if
          the file is present and ignored if the file is absent.

christos

PS: I dislike the pam configuration file syntax....