[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PAM authentication patch - v2
From: |
Mark D. Baushke |
Subject: |
Re: PAM authentication patch - v2 |
Date: |
Sun, 20 Apr 2003 19:43:06 -0700 |
Brian Murphy <brian@murphy.dk> writes:
> Derek Robert Price wrote:
>
> >
> > Brian, you seem to know enough to include a few of these with your patch?
> >
> > Derek
> >
> May I present the newest and shiniest PAM authentication patch for
> cvs.
>
> I have included a pam configuration for Linux and Solaris (Untested
> due to lack of root access on such a system), a small bug fix and some
> updated and extended documentation.
>
> I am on holidays until next week so expect a little delay in my
> responses to mails (up to a week ;-)).
>
> /Brian
> +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.
The rest of the paragraph is awkward and confusing.
> +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
Note: I would rather not see "i.e." in anything other than parenthetical
expressions.
> +allow password change which is a practical barrier to
> +the password ever getting changed, see below. Users are
> +much more willing to change their password regularly
> +if they only have to remember one. Another alternative
> +here is some sort of web based access to the cvs password
> +file.
A possible replacement for the awkard parts of the paragraph might be
the following:
On the other hand, PAM makes it very easy to change your password
regularly. If they are given the option of a one-password system for
all of their activities, users are often more willing to change their
password on a regular basis.
In the non-PAM configuration where the password is stored in the
@file{CVSROOT/passwd} file, it is difficult to change passwords on a
regular basis since only administrative users (or in some cases
processes that act as an administrative user) are typicaly given
access to modify this file. So, either there needs to be some
hand-crafted web page or set-uid program to update the file, or the
update needs to be done by submitting a request to an administrator do
perform the duty by hand. In the first case, having to remember to
update a separate password on a periodic basis can be difficult. In
the second case, the manual nature of the change will typically mean
that the password will not be changed unless it is absolutely
necessary.
Note that PAM administrators should probably avoid configuring
one-time-passwords (OTP) for @sc{cvs} authentication/authorization. If
OTPs are desired, the administrator may wish to encourage the use of
one of the other Client/Server access methods. See the section on
@pxref{Remote repositories} for a list of other methods.
It may be that there is a more concise way to say the above, but the
original paragraph was confusing to me and seemed to imply the above
information only to the informed user who would not be the consumer of
the page at hand.
I hope that the above is useful in crafting the words that will
eventually go into this manual.
Note: Somewhere along the line, it may be desirable to mark the PAM
feature as an experimental feature that may not make it into a fully
released version of cvs and suggest positive feedback of the feature be
sent to the either the bug-cvs or info-cvs e-mail addresses.
Enjoy!
-- Mark
- Re: PAM authentication patch - v2, (continued)
- Re: PAM authentication patch - v2, Derek Robert Price, 2003/04/16
- Re: PAM authentication patch - v2, Brian Murphy, 2003/04/16
- Re: PAM authentication patch - v2, Brian Murphy, 2003/04/17
- Re: PAM authentication patch - v2, Mark D. Baushke, 2003/04/17
- Re: PAM authentication patch - v2, Derek Robert Price, 2003/04/17
- Re: PAM authentication patch - v2, Larry Jones, 2003/04/17
- Re: PAM authentication patch - v2, Derek Robert Price, 2003/04/17
- Re: PAM authentication patch - v2, Mark D. Baushke, 2003/04/17
- Re: PAM authentication patch - v2, Derek Robert Price, 2003/04/18
- Re: PAM authentication patch - v2, Brian Murphy, 2003/04/20
- Re: PAM authentication patch - v2,
Mark D. Baushke <=
- Re: PAM authentication patch - v2, Brian Murphy, 2003/04/27
- Re: PAM authentication patch - v2, Mark D. Baushke, 2003/04/28
- Re: PAM authentication patch - v2, Brian Murphy, 2003/04/28
- Re: PAM authentication patch - v2, Derek Robert Price, 2003/04/29
- Re: PAM authentication patch - v2, Max Bowsher, 2003/04/17
- Re: PAM authentication patch - v2, Mark D. Baushke, 2003/04/17
- Re: PAM authentication patch - v2, Larry Jones, 2003/04/16
- Re: PAM authentication patch - v2, Max Bowsher, 2003/04/17
- Re: PAM authentication patch - v2, Brian Murphy, 2003/04/18
Re: PAM authentication patch - v2, Brian Murphy, 2003/04/15