Re: PAM authentication patch - v2

[Mark D. Baushke]

Derek Robert Price <derek@ximbiot.com> writes:

> Brian Murphy wrote:
> 
> > This is, I'm afraid, very system dependant. Sun has no /etc/pam.d, just
> > an /etc/pam.conf and also requires
> > (it seems) a full path to the module:
> >
> > login auth required /usr/lib/security/$ISA/pam_unix.so.1
> >
> > the ISA variable is to handle 32 and 64 bit variants. Linux has both
> > variants and other systems
> > probably have their own quirks. It seems like asking for trouble to try
> > and automate this. All
> > systems have a default "other" PAM configuration which cvs would use if
> > there was no specific
> > cvs configuration.
> 
> 
> Hrm.  Okay.  I'm not _too_ worried about incompatible systems at the
> moment, though we could deal with that using configure, at least in
> theory.  I may write one that works on my RH Linux before I commit
> this. We can let users with other requirements submit patches, perhaps.

You may wish to add a few sample files for the major variants of PAM to
the contrib directory. Not all Linux systems use the same configuration
as each other and they differ from Solaris which differs from AIX which
differs from Cray... you get the idea. Maybe a contrib/pam directory
for examples that folks end up using would make sense...

> > Here is the updated texinfo file.
> 
> 
> That looked good.  You missed a few of the texinfo features we use,
> but I'll add the ones I don't miss before I commit this.  :)

Good, I appreciate knowing that it will be done right. :-)

> Speaking of committing, if I read the discussion correctly and noone
> changed their mind without saying so, we're still at +1 developer
> votes:
> 
>     Larry: +1
>     Mark:  -1
>     Me:    +1
>     _________
>     Total: +1
> 
> 
> Any further objections to this going into experimental before I test
> it here and commit it?

No change here. I still vote -1.

For that matter, I'd rather generally discourage the use of the
:pserver: for anything other than anonymous read-only repository access.
However, I know that a number of systems are depending on :pserver:
(including cvshome.org), so I do not advocate removing this mechanism
at the present time...

There are a number of different implementations of the Pluggable
Authentication Modules (PAM). Documents like
http://www.dementia.org/~shadow/pam.html show provide information on
some of the divergent implementations of PAM.

The 'Linux PAM' (ported to a number of other systems) differs from the
Solaris PAM and both of them are different than the stuff that comes on
the more 'secure' systems out there. This is the primary reason why
there are multiple ways to configure PAM... they come from different
implementations of the mechanism.

Given that cvs is using a PAM service rather than a full login, it may
not be quite as bad as I have seen other folks struggling to use. 

Lots of the problems I have seen appear to arise from challenge-response
semantics when the administer is using PAM SKEY and OPIE modules (or the
SecurID Server PAM module) as the way to login. Given that these one
time password (OTP) models just will not work for cvs :pserver: it is
probably not as big a deal, but may require a FAQ entry if the feature
ever goes from experimental to fully supported.

(If you really want to deal with the possibility that a PAM module may
need to use multiple challenge-response transactions, you would need
some other transport layer than the current :pserver: protocol with the
single password token in ~/.cvspass and against such a new protocol
extension for cvs I would be MUCH more negative.)

I would rather that this new feature NOT be auto-detected and installed.
Rather, I think it needs to be explicitly requested and if it is then
able to auto-detect that it is possible to build, it do so otherwise
complain to the user and do the configure without PAM support.

I'd like to require additional documentation to let folks know that PAM
is NOT intended as the model to use for most :pserver: sites...

Caveat PAM support in the documentation as a non-default experimental
feature. If it gets some use by more than just the contributor and folks
like it, we can see about moving it to default configuration detection.
However, we are likely to need a much wider deployment base than just
Linux and Solaris before that happens.

        Thanks,
        -- Mark