Bug 835137 - lchsh fails to work
lchsh fails to work
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Vrabec
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-25 11:56 EDT by aeb
Modified: 2012-07-25 07:01 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-25 07:01:27 EDT
Type: Bug
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 aeb 2012-06-25 11:56:03 EDT
Description of problem:
A user wants to change her shell. She cannot.

Version-Release number of selected component (if applicable):
Fedora release 16, libuser-0.57.4-1.fc16.x86_64

How reproducible:

Steps to Reproduce:
1. chsh
chsh: chsh: can only change local entries.
2. lchsh
Changing shell for nnn.
Error initializing libuser: could not open configuration file `/etc/default/useradd': Permission denied.
3. reflect sadly on the progress of Unix/Linux/RedHat
  
Actual results:
The user cannot change her shell.

Expected results:
The user can change her shell.

Additional info:
The present problem was discussed in bugs 125611 (2004-06-09), 497333,
759605, but apparently not fixed in eight years. Sad.
(Since people can change their password, and the security requirements for changing passwords are identical to those for changing shell, all required code exists already.)
Comment 1 Miloslav Trmač 2012-06-25 12:21:30 EDT
Thanks for your report.

(In reply to comment #0)
> Steps to Reproduce:
> 1. chsh
> chsh: chsh: can only change local entries.
This is not explicitly said anywhere - I assume you are using some kind of centralized user information store, is that right?  Is it NIS, LDAP, or something else?

> 2. lchsh
> Changing shell for nnn.
> Error initializing libuser: could not open configuration file
> `/etc/default/useradd': Permission denied.

Right, the default configuration is not optimized for unprivileged users.

As a workaround, you can either
1) make /etc/default/useradd world-readable, or
2) manually migrate the settings from /etc/default/useradd into /etc/libuser.conf (as documented in libuser.conf(5)), and drop the default_useradd= line from /etc/libuser.conf .  An uprivileged user could even set up their own libuser.conf without root's cooperation.

The simplest way to get this working automatically would be to make /etc/default/useradd world-readable.  Peter, what do you think?  The contents of that file are not strictly necessary to be secret for the system to be secure, OTOH they are kind of sensitive because information about other accounts can be deduced from that file.


> Additional info:
> The present problem was discussed in bugs 125611 (2004-06-09), 497333,
> 759605, but apparently not fixed in eight years. Sad.
> (Since people can change their password, and the security requirements for
> changing passwords are identical to those for changing shell, all required
> code exists already.)
That's not actually true - PAM doesn't provide a way to change the shell, and "code exists" is not the same as "code can be safely run in a setuid program".  However, since 0.57 the libuser code does allow unprivileged usage for LDAP, currently it's "only" the default configuration that makes it difficult.
Comment 4 Jan Pokorný 2012-07-19 10:18:47 EDT
As per Fedora's devel list it is known, but just for related reference:

$ lid lp
Error initializing libuser: could not open configuration file
`/etc/default/useradd': Permission denied.

$ which lid
/usr/sbin/lid

$ rpm -qf $(which lid)
libuser-0.57.6-1.fc17.x86_64
Comment 5 Peter Vrabec 2012-07-20 05:03:25 EDT
hey guys, I suppose I miss something here.

1. it's not necessary to read /etc/default/useradd to change user's shell right?

2. even if:

$ ls -ld /etc/default/useradd 
-rw----r--. 1 root root 119 Feb  7 18:08 /etc/default/useradd
$ lchsh
Changing shell for pvrabec.
Error initializing libuser: not executing with superuser privileges.

which makes sense to me. Users's shell is in /etc/passwd which is 

$ ls -ld /etc/passwd
-rw-r--r--. 1 root root 2096 Jun 29 12:13 /etc/passwd

not writable for unprivileged users.
Comment 6 Miloslav Trmač 2012-07-20 10:03:07 EDT
(In reply to comment #5)
> hey guys, I suppose I miss something here.
> 
> 1. it's not necessary to read /etc/default/useradd to change user's shell
> right?

Well :)  libuser has a generic config system, and the configuration is read before even knowing whether superuser privileges (see "2.") will be required.  Of course, it is software, so it could be modified to not read /etc/default/useradd in such cases, but it would be a rather non-trivial change, and changing the permissions of the file would be much simpler.

> 2. even if:
> 
> $ ls -ld /etc/default/useradd 
> -rw----r--. 1 root root 119 Feb  7 18:08 /etc/default/useradd
> $ lchsh
> Changing shell for pvrabec.
> Error initializing libuser: not executing with superuser privileges.
> 
> which makes sense to me. Users's shell is in /etc/passwd which is 
> 
> $ ls -ld /etc/passwd
> -rw-r--r--. 1 root root 2096 Jun 29 12:13 /etc/passwd
> 
> not writable for unprivileged users.

That's what happens with a configuration using the "files" and "shadow" modules, which update these files.  libuser can be configured to use an "ldap" module instead, which uses the LDAP protocol, which could be done by a non-root user - and the topic of this bug is that a non-root user can not actually use libuser to edit LDAP in the default configuration.
Comment 7 Peter Vrabec 2012-07-23 04:24:55 EDT
thnx. Miloslav for clarification. I had not realized that LDAP was a main concern here. 

well I'm not aware of any arguments against public readable /etc/default/useradd. Moreover it seems that readable "userad" is quite common in other Linux distros.
Comment 8 Miloslav Trmač 2012-07-23 04:38:15 EDT
(In reply to comment #7)
> well I'm not aware of any arguments against public readable
> /etc/default/useradd. Moreover it seems that readable "userad" is quite
> common in other Linux distros.

Thanks, reassigning to shadow-utils to change the permissions.
Comment 9 Peter Vrabec 2012-07-25 07:01:27 EDT
changed in shadow-utils-4.1.5-5.fc18

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