Re: severe deficiencies in our PAM setup

[Greg Stark <gsstark@mit.edu>]

Daniel Jacobowitz <dan@debian.org> 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
> PAM.

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.

-- 
greg