Bug 835137

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.

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

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.

(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.

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.

(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.

changed in shadow-utils-4.1.5-5.fc18