Description of Problem:
With a certain, not too obviously wrong, samba security configuration,
a normal user can change the root password by typing "smbpasswd username"
"username" will be the new root password afterwards.
Version-Release number of selected component (if applicable):
Relevant settings in smb.conf:
security = USER
encrypt passwords = yes
obey pam restrictions = no
pam password change = no
passwd program = /usr/bin/passwd
passwd chat = *New*password* %n\n *Retype*password* %n\n
unix password sync = yes
Steps to Reproduce:
1. as normal user (username e.g. jeff) (with entry in smbpasswd) type
2. When asked for password, type "jeff" again
User gets an error message, but the root password is now "jeff"
Error message: "smbpasswd jeff" is not a permitted usage for non-root users
Obviously smbpasswd takes "jeff" as the password and feeds it twice into
program, which is called as root, and therefore changes the root password
I think in step 2 above one can actually type anything, the information is
The problem is solved in samba 2.2.2, where the "passwd program" entry in
smb.conf must contain the string %u". However, in 2.2.2, smbpasswd
apparently still interprets the argument ("jeff" in the above example) as
I ran into this problem when experimenting with smbpasswd and noticing I
couldn't "su" anymore with the normal root password.
Obviously this is a combination of a misconfiguration of samba security and
a wrong usage
of smbpasswd. The configuration is not that obviously wrong, though; it
seems not too
unlikely that configurations like this could be used by administrators with
experience. The entry name "passwd program" does not suggest that arguments
like %u should be specified for the passwd command line. And "unix password
sync" is an attractive
option for all administrators who have a lot of users who connect only
The documentation of the "pam password change" option, that is obviously
"the Right thing",
was pretty obscure to me and I couldn't get it to work, therefore I started
experimenting with passwd chat. I have "pam password change" now working
with samba 2.2.2.
I can't reproduce this.
Anyway, as the %u is there in the supplied configuration file there should be no
reason to remove it. If you want to create a hole-filled configuration, it's
certainly possible in many programs .
%u is _not_ in the default configuration. It is only present as in a comment
in smb.conf. it will therefore not be seen by users who (like me) use SWAT
for samba administration. The samba default is "/bin/passwd", a program that
even exist on RedHat distributions. Similarly, the "passwd chat" default will
on any RedHat system. I wonder why RedHat doesn't change these defaults such
they fit their distribution, but that's a different issue.
The documentation (in the release in question) was also not explicit about "%u",
and the option name "passwd program" does not suggest that one should put
the value of that option.
By no means did I intend to create a "hole-filled configuration". On the
contrary, I am usually
pretty concerned about security. And it was not the first time I configured a
only the first time I felt the need to use "unix password sync".
As I mentioned already, the problem is solved by samba 2.2.2. I just wanted to
aware something like this could happen.
As I often mention, this is one of the major reasons I added 'pam password
change' to Samba. It is much less prone to this kind of stuff-up. Also, 2.2.2
now doesn't allow a password change as root without %u.