Re: PAM Authentication?

[Jeff Smith]

--- Todd Denniston <address@hidden>
wrote:

> Jeff Smith wrote:
> > 
> > I am trying to bring cvs into my company.  I am
> > working with one of our Solaris admins on getting
> the
> > product installed and configured.
> > 
> > We have run into a problem with getting the PAM
> > authentication working.
> > 
> > I really don't know anything about PAM, my admin
> > probably does, but we have followed the
> instructions.
> > 
> 
> Which instructions?
> I see no PAM here
>
https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_26.html#INDEX1_6
> Or here
>
https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_27.html#INDEX2_2
> 
The information here:
https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_2.html
talks about pam authentication.

I've done some more reading and I didn't realize PAM
support was that newly introduced into CVS.

> 
> Is y24jds a username at the OS level, i.e., not just
> for CVS?
> if it is then pserver should just use the system's
> login, or something close
> to it, which would automatically use PAM.

Yes, y24jds is a valid unix username that can log into
the system fine.  So you are saying that pserver just
knows how to authenticate valid unix users on the
system and we shouldn't of had to configure anything
else?

> 
> <SNIP>
> > When I do the command:
> > 
> > cvs -d :pserver:address@hidden:/cvs login
> > it does prompt for a password, and I put in the
> right
> > one.
> > 
> > But I get:
> > cvs login: authorization failed: server cvsdev
> > rejected access to /cvs for user y24jds
> > 
> > In the /var/adm/messages, I see the output:
> > 
> > cvs[26366]: [ID 926525 daemon.notice] login
> failure
> > (for /cvs)
> <SNIP>
> > We also might have another complication entering
> in.
> > Our Unix servers run a very intrusive security
> program
> > called E-Trust.  It is so powerful that it can
> even
> > limit what root can do.  We have a data security
> team
> > that administers it, but trobuleshooting with them
> can
> > be difficult sometimes and I'm not really sure it
> is a
> > factor yet.
> 
> Is there a reason why you have chosen pserver as
> your connection method?
> From the sound of it, your group would be a bit more
> on the paranoid side
> and would expect after reading a bit on pserver
> security
>
https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_2.html#SEC33
>
http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=pserver+security&submit=Search%21&idxname=info-cvs&max=20&result=normal&sort=date%3Alate
> that pserver would be disallowed.
> 
> I would have more expected you to use :ext: with
> CVS_RSH=rsh or CVS_RSH=ssh
>
https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_2.html#SEC29

We are using pserver because our developers use IBM
WSAD with its built-in CVS support and out of the box
it supports pserver.  I see hooks in WSAD where you
can specify an external connection method, but I'll
have to research and see what it would take to make
that work.

The CVS server is all internal and we arn't worried so
much about locking it up tighter than a drum.  Our
data security team just likes to put these very
intrusive and complicated security products on our
servers which usually end up just giving people like
me big problems trying my software which needs to
share the same server working.

I might just have to fall back to the hand-maintained
password file for our users.  I only have about 35-50
that would be in it.

Thanks.