Bug 125611 - chfn, chsh, do not work with LDAP, even though they are linked to PAM.
chfn, chsh, do not work with LDAP, even though they are linked to PAM.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Ben Levenson
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-09 08:25 EDT by Paul Jakma
Modified: 2011-12-02 15:30 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 01:51:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Jakma 2004-06-09 08:25:07 EDT
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:
Comment 1 Elliot Lee 2004-06-11 13:48:45 EDT
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.
Comment 2 Matthew Miller 2005-03-17 23:22:00 EST
They also don't work with kerberos passwords, even if the user account itself is
local.
Comment 3 Matthew Miller 2005-04-27 18:49:24 EDT
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.
Comment 4 Steve Knodle 2005-04-29 13:12:15 EDT
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.
Comment 5 Matthew Miller 2005-04-29 13:46:01 EDT
Hey Steve -- I actually see the problem with tcsh as the shell too.
Comment 6 Steve Knodle 2005-04-29 15:20:32 EDT
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.
Comment 7 Tomas Mraz 2005-09-12 11:17:46 EDT
See also bug 138208

Note that more than PAM-ification it would be a libuser-ification.
Comment 8 Miloslav Trmač 2005-09-12 11:45:34 EDT
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.
Comment 9 Miloslav Trmač 2005-09-12 11:49:53 EDT
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.
Comment 10 Miloslav Trmač 2005-09-12 11:57:35 EDT
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?
Comment 11 Tomas Mraz 2005-09-14 05:41:36 EDT
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.
Comment 12 Paul Jakma 2006-02-08 05:26:54 EST
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.
Comment 13 Matthew Miller 2006-07-10 18:15:14 EDT
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!
Comment 14 Paul Jakma 2006-07-11 13:16:19 EDT
$ chfn
chfn: can only change local entries; use ypchfn instead.

Still same with FC5.
Comment 15 Matthew Miller 2006-07-11 13:18:54 EDT
Okay, thanks.
Comment 16 petrosyan 2008-03-10 01:00:41 EDT
Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 8?
Comment 17 Jason Tibbitts 2008-03-10 01:05:33 EDT
Yes, even in current rawhide:

> chfn
chfn: can only change local entries; use ypchfn instead.

> cat /etc/fedora-release
Fedora release 8.90 (Rawhide)
Comment 18 Bug Zapper 2008-11-26 01:47:40 EST
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
Comment 19 Bug Zapper 2009-01-09 01:51:06 EST
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.
Comment 20 Herbert Gasiorowski 2009-04-23 02:30:07 EDT
Still in Fedora 10:

both chsh and lchsh will not work!
Comment 21 Tomas Mraz 2009-04-23 02:39:33 EDT
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.
Comment 22 Herbert Gasiorowski 2009-04-23 05:51:49 EDT
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
Comment 23 Tomas Mraz 2009-04-23 05:59:28 EDT
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.
Comment 24 Aleksey Nogin 2011-03-23 14:16:50 EDT
(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.
Comment 25 Andrew Case 2011-12-02 14:57:02 EST
I'm looking how to deal with this in RHEL6 also.  If anyone can point me in the right direction.
Comment 26 Matthew Miller 2011-12-02 15:06:05 EST
To my knowledge there are no separate bugs.
Comment 27 Andrew Case 2011-12-02 15:30:07 EST
I opened bug#759605

Note You need to log in before you can comment on or make changes to this bug.