Re: PAM authentication patch - v2

[Mark D. Baushke]

Hi Brian,

Concerning your most recent proposed change to the documentation... I
have one nit here:

>+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 that the comma above should probably be on the previous line
directly after the word as in 'file,' rather than as a separate token.
Also, the latin abbreviation for id est ("i.e.") is typically done as a
parenthetical (i.e., for example) rather than in open text.

If you intend to put it into an open sentence, using the English
translation "that is" may read slightly better in most cases.

In this particular case, I believe both the sentence and the entire
paragraph may need some additional work.

Possibly something like:

  On the other hand, PAM makes it very easy to change your password
  regularly. This is impossible for a non-administrative user to do
  without access to modify the @file{CVSROOT/passwd} on the server. That
  is, the user needs rights to update the password file in the
  repository and cvs itself does not provide an easy method to change
  the password, so if the administrators of cvs do not provide an easy
  mechanism for update, most users will never change their password (see
  below). In many cases, the password may be generated by the cvs
  administrator and assigned to a user who will do a single 'cvs login'
  and promptly forget the password.

  Administrators of PAM authentication may set policy on the expiration
  of passwords to enforce both the time that a password may be used as
  well as specifying how long or short or what kind of character mix
  must go into making a new password. So, the administrator has nearly
  the same control over the characteristics of a non-PAM password, but
  the user is more likely to be willing and able to change their
  password on a regular basis. It is also helpful that the user will be
  less likely to forget their password if it is for everything in a
  single sign-on shop.

might give a flavor better suited to the manual. Of course, I do not
wish to presume to put words into your mouth concerning the use of the
new PAM feature you have coded. The above is just an example of another
way of trying to express what I think you were trying to say...

>+allow password change which in my experience means 

FYI. The use of 'my' in this sentence strikes me as the wrong way to go.
There are multiple authors of this document and we each of us may have
difference experiences. If possible, personalized anecdotal experience
of this kind of thing should probably not be used when writing
extensions to the documentation with attribution of the person writing
the text. So, the above phrase might read:

  allow password change which, according to the observational experience
  of at least Brian Murphy, means

Well, I think you get the idea I am trying to convey here...

>+the password never gets changed, see below. Users are
>+much more willing to change their password regularly
>+if they only have to remember one. 

For what it is worth, many systems that use the :pserver: have a
web-based mechanism for altering the contents of an individual's
:pserver: password. Just because it does not come as a standard part of
cvs does not mean it does not happen. For example, www.cvshome.org has a
servlet to allow users to change their passwords and that password is used
in the :pserver: access.

If you are going to try to make the point that PAM is easier to use,
please remember that there are other ways to do it and suggest that it
is possibly just easier to administer with the other attributes of an
organizational network login in a unified manner. I will admit that
administration of a user's CVSROOT/passwd file entry is typically an ad
hoc situation rather than one that is well integrated with the other
passwords used by the user.

        Enjoy!
        -- Mark