Re: severe deficiencies in our PAM setup
Daniel Jacobowitz <email@example.com> writes:
> On Sun, Sep 24, 2000 at 11:08:45PM -0500, Manoj Srivastava wrote:
> > Given the advantages if file inclusion, conditional sections,
> > etc, I would think that the advantages outwiegh the objections in
> > this case.
> > I would rather we had a well known, and still simple, approach
> > like using cpp rather than reinventing the wheel yet again to provide
> > equivalent benefits.
> On the other hand, I don't really desire to trust a CPP parser - it's a
> very complicated pile of code. And while it is fairly efficient, I
> still don't want to see it run every time a service authenticates via
I assume he's thinking of running it when a package installs itself and
providing a script for sysadmins so they can update their global configuration
and rewrite all the pam.d scripts automatically.
That's another approach, perhaps better than implementing inheritance in pam
but I would like to get some agreement with RedHat and have a basically
compatible configuration if we went that route.
I'm still leaning towards implementing a pam module that takes an service name
argument and calls the pam functions recursively with that service name. Are
the pam functions reentrant?
Incidentally, I would _not_ use CPP for anything other than C source. It's not
only a complicated piece of code it has to follow a complicated spec (ANSI C)
that is very specifically geared towards C source. CPP's whitespace and token
lexer are not appropriate for arbitrary files.
Using a dedicated preprocessor like M4 is a better idea, though that has the
disadvantage that sysadmins are less familiar with m4 so anything complicated
is probably a bad idea. But I don't think we really need much, just basic
macros and include files.