Password aging in passwd, differing chfn implementations

[Matt Wilson]

On Tue, Feb 26, 2002 at 01:53:53PM +1100, Christopher Yeoh wrote:
> 
> We did spend some time discussing it and the decision has been
> mentioned on this and/or lsb-spec list a few times since then, but to
> be honest I don't remember the details. Maybe someone else who was
> there can remember better than me.

The flags need to match the way finger interprets GEOS fields in the
passwd entry.  Currently there is a mismatch on systems like Debian,
where finger outputs:

Login: msw				Name: Matthew Wilson
Directory: /home/msw			Shell: /bin/bash
Office: Centennial, 555-1212		       Home Phone: 555-2424

(a la BSD finger, which almost EVERYONE uses, which is good)

and chfn takes:
Usage: chfn [ -f full_name ] [ -r room_no ] [ -w work_ph ] [ -h home_ph ]

The room_no entry is clearly displayed in finger as Office.

We're planning on adding aliases to our chfn to meet LSB 1.1.0, but
I'd like to point out here that this stuff is 1) mismatched on Debian
and SuSE and correct on Red Hat Linux, Mandrake, and others 2) of
little to no use for the ISV.  (and we're not going to change the
output of finger to say 'Room number:'.)

>
> As you've discovered to take the common subset of functionality
> between the two versions of sets of commands (and its not limited to
> passwd and chfn) its necessary to both remove a number of options and
> add extra commands to the specifications. I'd consider this to be a
> significant change to the specification and not just a fix of
> something obviously wrong.

We're going to add password aging support to passwd but there's an
important thing to keep in mind here.  Passing aging is not
implemented in the same way on all authentication mechanisms.  The
kerberos aging support is not the same as shadow.  We're adding aging
support to our passwd, but if the underlying authentication mechanism
doesn't support the kind of aging that the LSB is specifying here,
passwd will print an error and return an non 0 exit code.  It would be
nice to clarify the spec to handle the error cases.  For example:

-x max
    sets the maximum number of days a password remains valid.  If the
    underlying authentication mechanism does not support password
    aging then...

In general the error conditions in this section are very incomplete.

Cheers,

Matt