chsh: Permission denied (nss_ldap/pam_ldap server)

nbari

nbari

I have a server using nss_ldap/pam_ldap (all users are stored on an ldap directory) but few users have been available to change their shell using the command chsh -s /bin/sh. While others while trying to do so they get a
Code: 
chsh: Permission denied

Any idea of how to fix or make it work for all the users?

Here is a demo account in case someone would like to try and found how to do it:

Code: 
host: sign.io

user: [email]test@sign.io[/email]
pass: sssss

I do not know if this could be a bug that could be overpassing the ldap directory and storing the new user information and password on /etc/passwd - /etc/master.passwd.

The default login.conf has this configuration:

Code: 
default:\
  :passwd_format=blf:\
  :minpasswordlen=6:\
  :copyright=/etc/COPYRIGHT:\
  :welcome=/etc/welcome:\
  :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
  :path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin ~/bin:\
  :nologin=/var/run/nologin:\
  :cputime=1h:\
  :datasize=10M:\
  :stacksize=2M:\
  :memorylocked=2M:\
  :memoryuse=8M:\
  :filesize=10M:\
  :coredumpsize=0:\
  :openfiles=50:\
  :maxproc=10:\
  :sbsize=unlimited:\
  :vmemoryuse:16M:\
  :priority=5:\
  :ignoretime@:\
  :requirehome=1:\
  :idletime=30:\
  :umask=077:

The users that have successfully changed their shells using chsh have an entry on the /etc/passwd and /etc/master.passwd on the password field have a hash like this:

Code: 
test4:$1$YAvOssdO$JjZcAPX/4QppDIPlS2P4s.:4658:4658::0:0:test:/home/users/t/e/s/test4:/bin/sh

Where in theory they should have a hash beginning with $2 (since blf) is specified on the login.conf.

Any ideas of what could it be wrong?

regards.
 
Users that have an LDAP account shouldn't appear in /etc/passwd or /etc/master.passwd at all.
 
Exactly, that is why I am confused with this and would like to find the 'bug' that alters or bypasses the LDAP.

So far I have noticed that this happened only to newly created users, and later after the user changed his password he can not write to /etc/passwd or /etc/mater.passwd.
 
nbari said:
Exactly , that is why I am confuse with this and would like to find the 'bug' that alters or bypass the LDAP.
Click to expand...
The 'bug' is most likely caused by the person that created the accounts. Instead of creating LDAP accounts s/he created local accounts.

So far I have noticed that this happened only to newly created users, and later after the user changed his password he can not write to /etc/passwd or /etc/master.passwd.
Click to expand...
Keep in mind that tools like passwd(1) and chsh(1) can't operate on LDAP. Only local and NIS accounts are supported.
 
Accounts are never created using adduser or locally, accounts are created via web, writing to an ldap server. Later the server giving ssh only queries the ldapserver with nss_ldap/pam_ldap.

But NO accounts are created locally (give a try at http://www.sign.io).

Now the users change their password using an alternate 'passwd' command, like the one specified here: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/ldap-auth/article.html

And as you properly say, chsh(1) "should not not operate on LDAP" but in this server something strange maybe a 'BUG' is allowing chsh to work even when the user is not on the on the /etc/master.passwd.

I do not know if maybe the ssh or something related to pam* in the process of forking to the logged users bypasses the ldap or the nsswitch.conf. It looks like this:

Code: 
group: files ldap
hosts: files dns
networks: files
passwd: files ldap
shells: files
services: files
protocols: files
rpc: files
I have noticed that this only happens or is vulnerable until the user changes his password (via ldap) no local user, after that chsh behaves like it is supposed to be working.
 
nbari said:
I have notice that this only happens or is vulnerable until the user change his password (via ldap) no local user, after that chsh behaves like supposed to be working.
Click to expand...
I would take a long hard look at this script. It sounds like it gets the data from LDAP properly but instead of saving the new password in LDAP it somehow creates a local account.

Since the local accounts have precedence over LDAP (see your nsswitch.conf) it will look like everything works. But instead of authenticating to LDAP it's now using the local accounts. This might also explain why chsh suddenly works after this (as it's able to find and change the local account).
 
If I am right I think it's more an issue with chsh, since somehow it requests the password for making changes but the password should only work for local users since in theory chsh is only for manipulating the local db.

It should output something like:
Code: 
passwd: Sorry, `passwd' can only change passwords for local or NIS users.
(this is the output of the passwd) command

What I think 'chsh' is doing, it checks and validates that the user exists on the ldap (that is why it shows the id and current path) but on the time of saving it overrides the nsswitch.conf and the password entered is the one used for creating the none existing user since locally there is no user, this is why later the user can login to the system with his stored (initial password on ldap) and later change his configuration using another password.

Now I do not know if this is a bug or is a behavior of chsh, any ideas?
 
Should be fairly easy to test, just create a new user in LDAP and try to use chsh on that account. Look at the /etc/passwd file before and after. Then do the same with your password reset tool.
 
Creating the new user on ldap (live example on http://www.sign.io) does not add any user to /etc/passwd on the ssh server.

The newly created user can log in on the server and do a cat also to /etc/passwd and notice that there is no info related to this new user. but if it executes chsh -s /bin/sh, it asks for a password, after that a new entry is added to /etc/passwd, and later if the user changes his password (the one is stored on ldap) he can sign out an sign in again but this time the chsh -s /bin/sh will not work with this new password since it need to use the one used previously and it is stored on /etc/passwd.

Now if the user changes his password before trying to execute the chsh, after changing it chsh works as expected.
 
nbari said:
the new created user can login the the server and do a cat also to /etc/passwd and notice that there is no info related to this new user.
Click to expand...
That sounds good.

but if it executes chsh -s /bin/sh , it ask for a password,
Click to expand...
This is odd, normally chsh doesn't ask for a password.

after that a new entry is added to /etc/passwd,
Click to expand...
This should certainly not happen.

and later if the user change his password (the one is stored on ldap) he can sign out an sign in again but this time the chsh -s /bin/sh will not work with this new password since it need to use the one used previously and it is stored on /etc/passwd.
Click to expand...
Yes, this is understandable. It's what happens when the user exists both locally and in LDAP.
 
You must log in or register to reply here.
Back
Top