From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Galeon/1.3.14 Description of problem: chfn, chsh refuse to work for anything but local access. They will not work for any kind of directory service, eg LDAP. I have a vague memory that in some previous RHL release these utilities were directory aware (possibly because they were supplied by way of pwdutils instead of util-linux, i'm not sure). That they are not directory service aware is annoying, especially when dir-aware versions of these utils exist. Either support for, at least, LDAP should be implemented in LDAP, or else these utilities should be provided by some other package that is directory aware. LDAP integration elsewhere in RHL/RHEL/FC is excellent (eg authconfig), it's a shame that the basic traditional unix utils do not work. Either the tools should understand these services, or PAM should be extended to cover updating all basic Unix account information, not just password, or if PAM already does support this (dont think it does) the utils concerned should use PAM obviously. Version-Release number of selected component (if applicable): 2.12-18 How reproducible: Always Steps to Reproduce: 1. type chfn or chsh at command prompt 2. press return 3. Actual Results: you get the message (figuratively): $argv[0]: can only change local entries; use yp$argv[0] instead. Expected Results: I expect to be prompted for new shell or new GECOS information in the usual way, regardless of whether my account information is defined locally, in NIS, in LDAP or whatever, as, my vague memory seems to suggest, certain older versions of RHL once used to do. Additional info:
This is not likely to happen anytime soon because there's so much work involved. It would probably require writing a whole directory access framework. nalin may be able to comment on any plans we have there.
They also don't work with kerberos passwords, even if the user account itself is local.
Moving to FC3 this doesn't get killed by my own FC2/Legacy cleanup campaign. This still affects FC3, and is likely to affect rawhide as well.
Note that "chsh" works properly if your shell is "tcsh", not bash. Even with my Kerberos password. It might be a bug in bash, or missing LOCALE files.
Hey Steve -- I actually see the problem with tcsh as the shell too.
Try (this worked for me on ubik: Fedora Core 3): logged in with bash as my login shell (from /etc/passwd) Start tcsh with: tcsh "chsh" fails for me until I : setenv LANG C Then "chsh" succeeds. But this trick doesn't let me change back. On another machine (kpc1): My login shell is "tcsh", and I can chsh to bash, but not back. Personally I think it is a combination of login environment and presence of proper LOCALE files that determines whether or not it works.
See also bug 138208 Note that more than PAM-ification it would be a libuser-ification.
There already is lchsh and lchfn, but I can't say whether they are safe enough to be configured setuid root without an extensive review. If you know the necessary ldap bind DN and password, they should work.
Sorry, let me try again.. There already is lchsh and lchfn, but I can't say whether they are safe enough to be configured setuid root without an extensive review. (this would also require making /etc/libuser conf at most rw-------). If the user knows the LDAP bind DN and password necessary to modify the relevant fields, they should work when run as non-root.
I was wrong. They require PAM authentication, so they have to be setuid root to work when run as non-root. Sorry about the mistake. Tomas, could you please look at libuser/apps/apputil.c:lu_authenticate_unprivileged(), whether it looks sane?
For complete correctness the pam_get_item in the error paths should be called this way: if(pam_get_item(..,&puser) != PAM_SUCCESS || puser == NULL) { puser = user } Also the puser == NULL should be tested before strcmp-ing it to user.
Miloslav, Native LDAP-aware chfn, chsh really absolutely should *not* be setuid-root. The only authorisation that should be required is the users own credentials, the LDAP directory should be configured to allow access to the required attributes by self. If this is done via PAM, I guess it's more tricky. Even if LDAP only needs user privileges - the design of PAM probably requires elevated privileges be kept. Could be tricky.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
$ chfn chfn: can only change local entries; use ypchfn instead. Still same with FC5.
Okay, thanks.
Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 8?
Yes, even in current rawhide: > chfn chfn: can only change local entries; use ypchfn instead. > cat /etc/fedora-release Fedora release 8.90 (Rawhide)
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Still in Fedora 10: both chsh and lchsh will not work!
chsh cannot modify user information in LDAP server. lchsh should work if you configure the libuser.conf properly, namely the [ldap] section there must be properly filled in and modules and create_modules in the [defaults] section must contain ldap.
Thank you - lchsh now works! But - you have to enter the passwd twice - it needs root-Access - though it is not needed for this ldap modification (only for the first passwd check) - chsh still gives a hint to use ypchsh instead
Problems/RFEs agains lchsh should be reported against libuser in a new bug. A RFE to improve the hint in chsh should be reported as a separate bug too.
(In reply to comment #23) > Problems/RFEs agains lchsh should be reported against libuser in a new bug. > > A RFE to improve the hint in chsh should be reported as a separate bug too. Have these separate bugs been ever filled? These issues still exist in RHEL 5.6 and are a problem.
I'm looking how to deal with this in RHEL6 also. If anyone can point me in the right direction.
To my knowledge there are no separate bugs.
I opened bug#759605