bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PAM authentication patch - v2


From: Brian Murphy
Subject: Re: PAM authentication patch - v2
Date: Thu, 17 Apr 2003 10:14:13 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1

Derek Robert Price wrote:

> Brian Murphy wrote:
>
>> Derek Robert Price wrote:
>>
>>> Brian, your patch looked good, though I haven't attempted to install
>>> it yet, but it will still need manual (doc/cvs.texinfo) additions
>>> before it can be committed.
>>
>>
>> How is this?
>
>
>
> Now that I'm thinking about it, how about installing a default
> /etc/pam.d/cvs file which duplicates the old system password behavior
> when CVS is compiled to use PAM?


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.

Here is the updated texinfo file.

/Brian

Index: doc/cvs.texinfo
===================================================================
RCS file: /cvs/cvs/doc/cvs.texinfo,v
retrieving revision 1.1.1.2
retrieving revision 1.4
diff -u -r1.1.1.2 -r1.4
--- doc/cvs.texinfo     13 Apr 2003 20:34:16 -0000      1.1.1.2
+++ doc/cvs.texinfo     16 Apr 2003 18:33:03 -0000      1.4
@@ -2489,13 +2489,62 @@
 the username and password using the operating system's
 user-lookup routines (this "fallback" behavior can be
 disabled by setting @code{SystemAuth=no} in the
address@hidden @file{config} file, @pxref{config}).  Be
-aware, however, that falling back to system
address@hidden @file{config} file, @pxref{config}).
+
+The default fallback behaviour is to look in 
address@hidden/etc/passwd} for this system password but if your
+system has PAM - Pluggable Authentication Modules - 
+and cvs is comfigured to use it at compile time then
+cvs will use that instead. This means that with a 
+global configuration file usually @file{/etc/pam.conf}
+or possibly @file{/etc/pam.d/cvs}
+you can tell cvs to use LDAP or normal UNIX passwd 
+authentication or many other possibilities - see your
+PAM documentation for details. CVS needs an "auth" 
+and "account" module in the PAM configuration file. 
+Using PAM gives the system administrator much more 
+flexibility in how cvs users are authenticated but 
+no more security than other methods, see below. 
+
+A typical PAM configuration would have the following lines 
+in @file{/etc/pam.conf} to emulate the standard cvs system 
address@hidden/etc/passwd} authentication:
+
address@hidden
+cvs    auth        required    pam_unix.so
+cvs    account     required    pam_unix.so
address@hidden example
+
+The the equivalent @file{/etc/pam.d/cvs} would contain
+
address@hidden
+auth       required    pam_unix.so
+account            required    pam_unix.so
address@hidden example
+
+Some systems require a full path to the module so that
address@hidden (Linux) would become something like 
address@hidden/usr/lib/security/$ISA/pam_unix.so.1} (Sun Solaris).
+
+Be aware, however, that falling back to system
 authentication might be a security risk: @sc{cvs}
 operations would then be authenticated with that user's
 regular login password, and the password flies across
 the network in plaintext.  See @ref{Password
 authentication security} for more on this.
+This may be more of a problem with PAM authentication
+because it is likely that the source of the system 
+password is some central authentication service like
+LDAP which is also used to authenticate other services.
+On the other hand PAM makes it very easy to change 
+your password regularly - this is impossible to do 
+for a user authenticated via cvs' private password file
+without total access to the @file{CVSROOT/passwd} file 
+, i.e. the user needs all rights to the repository to 
+allow password change which in my experience means 
+the password never gets changed, see below. Users are
+much more willing to change their password regularly
+if they only have to remember one. 
 
 Right now, the only way to put a password in the
 @sc{cvs} @file{passwd} file is to paste it there from


reply via email to

[Prev in Thread] Current Thread [Next in Thread]