Red Hat Bugzilla – Bug 138208
chage, chfn, useradd, userdel, usermod not PAMified
Last modified: 2007-11-30 17:07:14 EST
Description of problem:
In pretty much all versions of Red Hat Linux, including Red Hat
Enterprise Linux v3, the common unix tools chage and chfn and the
slightly less popular userxxx utilities are not PAM-aware - they
directly manipulate the shadow suite files.
The SUSE linux distribution has solved this problem by incorporating
Thorsten Kukuk's pwutils, which are apparently a more evolved version
of the shadow-utils that are entirely PAM-capable. See
for SuSe's description page, or http://www.thkukuk.de/pam/pwdutils/
for Thorsten's download page.
If Red Hat does not wish to entirely abandon their own heavily
modified shadow-utils, I suggest "not re-inventing the wheel" and
incorporating Mr. Kukuk's chage, chfn, and userxxx utilities into the
package while retaining passwd, login, etc.
Version-Release number of selected component (if applicable):
ALL versions, ALL platforms
Attempt to modify an account known only through PAM (any account that
does not exist in /etc/passwd or /etc/shadow).
Steps to Reproduce:
1.Do a "chage -l" to a user account that exists in /etc/shadow
2.Note various dates are listed and can be changed
3.Do a "chage -l" to a user account that ONLY exists in LDAP
4.Note "chage: unknown user:" error message
Error indicating user does not exist, when user is easily capable of
logging in and normal functions like password expiration and session
setup through PAM work fine.
Normal chage function, which allows listing and modification of
various account age fields.
Bug reproduction uses chage, because that's an easy demonstration.
This same problem exists in chfn as well as the usermod, userdel, and
This is not a "requested enhancement", it's a bug, because the
utilities in question are not documented to be non-PAM in their man
pages, and because Red Hat EL is supposed to be a PAMmed, LDAP-capable
LDAP integration at the enterprise level *needs* these tools so that
heavily scripted systems can be brought into the LDAP fold cleanly and
easily. There are thousands of scripts that call these utilities,
particularly in manufacturing and automated industrial environments.
System security can be an issue depending on other factors (these may
include: security checking scripts that rely on chage will not work -
for example samba doesn't check for password expiration at the unix
level and logon scripts commonly distributed on the internet use chage
to check it, also group-based security schemes will be hard to
transport to LDAP if "usermod -G" is in the maintenance script as it
commonly is, etc. etc. etc.)
I have built and tested Thorsten Kukkuk's "chage" - I did *not* build
the rest of the pwdutils suite (yet, at least).
The only modification I see that would be necessary for proper
function on a Red Hat EL3 box is that it should get the binddn and
password from a configuration file and not the user. Chage already
has special handling for root users (e.g., only root may chage other
users accounts) and it should be possible for it to extract the
necessary values from /etc/ldap.conf (as do nss_ldap and pam_ldap on
Red Hat boxen) and /etc/ldap.secret.
I'm going to compare the useability and efficiency of Thorsten's code
with the perl chage that is distributed with padl as part of their
pam_ldap package, if I ever get the time. I prefer a compiled C
version to perl, of course, for this kind of thing, but since Red Hat
is distributing padl's code with only minor modifications perhaps it
would be a better fit.
It appears that I was misinformed... padl does not distribute a
"chage" with pam_ldap. They do distribute a PAMmed chfn and chsh (at
least in the current version which I just downloaded). I also pulled
down nss_ldap and there isn't any chage there either.
I am looking at Thorsten's code now, but my C is verra verra rusty Cap'n.
I've hacked together a perl "LDAP chage" that does the basic "chage -l
[user]" function. It reads the /etc/ldap.conf and /etc/ldap.secret if
the user is root, otherwise it asks for binddn and pass (supplying
reasonable defaults for binddn, I think).
If anyone wants a copy you can email me. I intend to improve the code
until it is a fully featured chage replacement and then put it out
under GPL, hopefully PADL will pick it up since they already ship an
A real PAMified chage.c would still be better, obviously.
I see from http://cvs.pld.org.pl/shadow/ChangeLog?rev=1.8 that Tomasz
Kï¿½oczko is willing to accept Red Hat code into the main line of the
PLD shadow utils (from which RHEL derives shadowutils). The latest
inclusion of RH code was two days ago, in fact, so there may no longer
be a need to maintain an RH fork.
Problem persists in RHEL4. Authconfig got fixed, and a more recent
version of OpenLDAP was used - those are big improvements! But the
shadowutils are still not all PAMmed... I tested chage and usermod,
they both still try to use /etc/shadow and /etc/passwd, respectively.
Thorsten Kukuk has released pwdutils 3.0.5 which can be found on ftp.kernel.org
and mirrors. Mostly minor bug fixes, but also fixed compilation problems
associated with new PAM.
Shadow-utils and PAM are not intended to modify a remote account.
NOTABUG close makes the statement "shadow-utils and PAM are not intended to
modify a remote account". While the definition of what shadow-utils is intended
for is up to Red Hat (since it's a RH package that is not supported by the
original authors J. & J. Haugh) that statement in regards to PAM is factually
incorrect. I personally have corresponded with Andrew Morgan on this issue, and
PAM was definitely designed right from the start to interact with remote
services such as NIS (and NIS equivalents like Hesiod and LDAP). PAM and NSS
are *specifically* intended to obviate distinctions between local and remote
Incidentally, the phrase "remote account" is contextually strange anyway, since
our LDAP server is on local loopback - most people will primarily need these
tools on their master LDAP server, I think.
NOTABUG close message also says "see libuser". According to bugzilla 99435, the
libuser in RHEL3 does not have a functional LDAP backend - this comment applies
to both the as-shipped and current-up2date versions - and therefore (according
to Red Hat) libuser does not supply a functional replacement for these
capabilities. Perhaps resolving the libuser issues (and making sure the libuser
tools can live up to their design goal of replacing most of the shadow-utils)
would be the best fix, but it seems to me (from reading 99435) that would
require a more recent version of libuser to be rolled out to RHEL3 customers via
Full LDAP and PAM capabilities are clearly achievable. Other distributions are
shipping functional, LDAP-capable, PAM-compliant utilities, including chage,
chfn, useradd, userdel, usermod. I have mentioned several examples already,
including SUSE's package which is FOSS and available to Red Hat.
If Red Hat does not wish to deliver a fully LDAP integrated solution, they
should probably stop referring to RHEL3 as LDAP capable, and instead say
somthing like "sort of useable in limited roles for the least demanding LDAP
users". Not trying to flame, here, just trying to be honest. We've got over 50
hospitals depending on us, and we'd like to be able to recommend Red Hat to them
as an OS that can make porting their elaborate existing infrastructures to LDAP
a straightforward task. Flaming people doesn't help my goals.
I know there are others watching this bugzilla... perhaps someone else can make
the case better than I can?