Bug 138208
| Summary: | chage, chfn, useradd, userdel, usermod not PAMified | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | redbugs |
| Component: | shadow-utils | Assignee: | Peter Vrabec <pvrabec> |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | jansen, j, k.georgiou, milan.kerslager, mitr, redbugs, tmraz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.suse.de/en/business/products/server/sles/packages/x86/pwdutils.html | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-02-14 13:13:57 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
redbugs
2004-11-05 18:25:13 UTC
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? |