1

I have a multi-user server, which puts a subset of the users in a chroot. I want to allow all users to call passwd in order to change their respective password. Everything else I can think of is either overkill or likely to compromise system-security.

I build my chroot with makejail using the following configuration.

chroot="/var/chroot/sshd"

cleanJailFirst=1
# these are binds to the actual location, hence, we don't want makejail to be tinkering with those.
preserve=["/home","/etc/passwd","/etc/group","/srv"]

testCommandsInsideJail=["bash","sh","ls","pwd","stat","whoami","svnserve -t","locale","localedef","man ssh","man scp","cat","nano","vim","ssh","scp","passwd"]
testCommandsOutsideJail=[]

packages=["coreutils"]

# speed up things a bit
sleepAfterStartCommand=0.8
sleepAfterTest=0.8

As you can see, in testCommandsInsideJail, I listed passwd, but if I login as my testuser (who is inside that chroot), I get:

$ passwd
Changing password for test.
(current) UNIX password: 
passwd: Authentication token manipulation error
passwd: password unchanged

which I don't understand unfortunately (before you ask, yes, I am sure the password I entered is correct). I have found some sites via g, which help me as little as the actual error message. To my understanding, I am missing some pam module, but I don't know how to add it to the python script that builds the jail.

I am running Ubuntu Server 10.04.

EDIT

I have the actual /etc/passwd bound (via /etc/fstab) to the location of the chroot passwd, which is in /var/chroot/sshd/etc/passwd, so modifications inside the chroot are seen from the outside. I have now also done the same with /etc/shadow, which for some reason I forgot before. So instead of

preserve=["/home","/etc/passwd","/etc/group","/srv"]

I have now

preserve=["/home","/etc/passwd","/etc/shadow","/etc/group","/srv"]

and an additional bind:

# chroot binds
/home       /var/chroot/sshd/home       none    bind    0   0
/etc/passwd /var/chroot/sshd/etc/passwd none    bind    0   0
/etc/shadow /var/chroot/sshd/etc/shadow none    bind    0   0
/etc/group  /var/chroot/sshd/etc/group  none    bind    0   0
/srv        /var/chroot/sshd/srv        none    bind    0   0

If I try to change the password now, I get

$ passwd
Changing password for test.
(current) UNIX password: 
Enter new UNIX password: 
Retype new UNIX password: 
passwd: Authentication token manipulation error
passwd: password unchanged

So, passwd manages to check the current password, but dies when it comes to setting it.

2
  • What OS, Linux?
    – Chris S
    Oct 27, 2010 at 13:17
  • 1
    Yes, I believe "Ubuntu Server 10.04" is Linux ;)
    – bitmask
    Oct 27, 2010 at 16:59

3 Answers 3

1

Even if you do get passwd into the chroot is it going to be useful? The passwd within the chroot is going to update the /etc/passwd or shadow in the chroot, not the system passwd/shadow. You will probably need to tell us more about what exactly you are serving out of this chroot since the details may help us provide you with a better answer.

1
  • Thanks for the hint, I completely forgot to provide /etc/shadow inside the chroot. Please see the part after EDIT.
    – bitmask
    Oct 27, 2010 at 2:25
1

You'd need to preserve the pam structures too (usually /etc/pam.d)

3
  • I added /etc/pam.d to the script and created a new bind. Inside the jail, I can see the correct directory. However, that did not change the error message.
    – bitmask
    Oct 27, 2010 at 17:07
  • A quick google suggests that this can arise with null passwords in /etc/shadow, or where /dev/urandom is not available in chroot (although this is uaully accompanied by more specific error messages) or where the cracklib datafiles are required and not in the chroot....try running the passwd through 'strace' and see if you can spot where it fails.
    – symcbean
    Oct 28, 2010 at 16:23
  • I have non-set (null?) passwords in my non-chroot shell, and passwd works fine there. Also, AFAIK cracklib is for checking if a password is admissible, which it does. If I enter for instance the password 1, passwd will refuse to set it and prompt me for a different password.
    – bitmask
    Oct 30, 2010 at 7:24
0

I had a similar problem, but I believe I built my chroot differently. Regardless, as the outer host of the chroot was a Fedora Linux system, I had to disable SELinux using setenforce 0 before I could successfully chroot /path/to/chroot /bin/bash and then use the passwd binary without getting an "Authentication token manipulation error."

Note that it had nothing to do with shadowed passwords vs unshadowed (you should always use shadowed), and I Was trying to change the root password inside the chroot, so it had nothing to do with a blank password, etc.

strace actually lead me down the wrong path in thi case.

Also, it appears to be kernel specific, as 4.17.14 worked without Disabling SELinux, but 4.17.9 required that I do so.

Anyway, on CentOS, Redhat or Fedora systems, with weird errors like that, turn off SELinux first and see if that helps. Just be sure to turn it back on, it's there to help.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .