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 http://www.suse.de/en/business/products/server/sles/packages/x86/pwdutils.html 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 How reproducible: 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 Actual results: 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. Expected results: Normal chage function, which allows listing and modification of various account age fields. Additional info: Bug reproduction uses chage, because that's an easy demonstration. This same problem exists in chfn as well as the usermod, userdel, and useradd utilities. 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 distro. 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 LDAP'ed chfn. 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. See: libuser
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 services. 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 up2date. 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?