[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: cvs with xinetd
From: |
USENBINZ |
Subject: |
RE: cvs with xinetd |
Date: |
Fri, 4 May 2001 14:20:36 +0200 |
CVS currently uses getspnam/getpwnam and crypt for system authentication.
For our environment I've slightly modified server.c to use Linux-PAM
(Pluggable Authentication Modules) instead (ie. replace getpwnam/crypt
with pam_authenticate). Using pam_unix.so alone basically does the same
thing the old code did (except that in your case it would have used the
correct encryption method), but as CVS is now a service on its own
regarding authentication (ie. there is a /etc/pam.d/cvs file)
authentication methods can be changed by just selecting different
PAM-modules. The changes are transparent to the clients (although a clean
PAM-solution would require changes to the clients as well, because the
password prompts etc. are provided by the PAM-modules).
Regards,
Stefan
Please respond to "Adam W. Montville" <address@hidden>
To: "Larry Jones" <address@hidden>, "Info-Cvs" <address@hidden>
cc:
Subject: RE: cvs with xinetd
After doing some experimentation, I think I've determined that enabling
MD5 passwords on my RedHat 7.0 box does, indeed, prevent OS-level
authentication by CVS. I built my box first with MD5 passwords enabled,
and configured CVS for a pserver, but could not connect from another
machine. Then, I build the box with "traditional" passwords enabled
(crypt(3)) and again configured CVS for a pserver. At this point, all
things were held equal except for the manner in which passwords were
generated. I can connect without a problem when MD5 passwords are
disabled.
I know that this isn't the best way to implement CVS, but I was curious.
Hopefully, I've stumbled across something that could use an update? Is
there a way to force CVS to use some other means than crypt(3) directly?
Regards,
Adam
-----Original Message-----
From: address@hidden [mailto:address@hidden Behalf Of
Larry Jones
Sent: Thursday, May 03, 2001 2:41 PM
To: address@hidden
Cc: address@hidden
Subject: Re: cvs with xinetd
address@hidden writes:
>
> The very fact that it uses the crypt(3) library function is why I
believe it
> would "break". Suppose I use jCVS to connect to my CVS server, on which
MD5
> passwords are used. Further suppose that I don't want to use the
layered
> password protection that CVS provides because I'm on an internal network
> protected elsewhere. jCVS will create the password in-line with the
fact
> that crypt(3) is used to generate it. However, the CVS pserver, not
having
> a passwd file, will look in the system files and find a password that
was
> generated with MD5. The passwords can't match, except by chance (and a
long
> shot at that).
That's not how it works; only the server uses crypt(), not the client.
The client simply "scrambles" the password (using a very weak, well
documented, invertible mapping which is intended simply to protect the
password from casual observation; like a lock on a screen door, it
serves no purpose as far as security is concerned) and sends it to the
server. The server then unscrambles the password to recover the
original plain-text password and calls crypt() to compare it with the
reference encrypted password from the CVS passwd file or the system
passwd file.
-Larry Jones
I wonder what's on TV now. -- Calvin
_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs
- Re: cvs with xinetd, (continued)
- Re: cvs with xinetd, Larry Jones, 2001/05/03
- RE: cvs with xinetd, adam_montville, 2001/05/03
- Re: cvs with xinetd, Larry Jones, 2001/05/03
- RE: cvs with xinetd, Adam W. Montville, 2001/05/03
- Re: cvs with xinetd, Larry Jones, 2001/05/04
- Re: cvs with xinetd, Peter Ajamian, 2001/05/05
- Re: cvs with xinetd, Larry Jones, 2001/05/05
- Re: cvs with xinetd, Peter Ajamian, 2001/05/05
- Re: cvs with xinetd, Peter Ajamian, 2001/05/05
- RE: cvs with xinetd, Gianni Mariani, 2001/05/06
RE: cvs with xinetd,
USENBINZ <=