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): 2.2.1a-4 How Reproducible: 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 "smbpasswd jeff" 2. When asked for password, type "jeff" again 3. Actual Results: User gets an error message, but the root password is now "jeff" Expected Results: Error message: "smbpasswd jeff" is not a permitted usage for non-root users Additional Information: Obviously smbpasswd takes "jeff" as the password and feeds it twice into the passwd program, which is called as root, and therefore changes the root password to "jeff". I think in step 2 above one can actually type anything, the information is unused. 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 a password. 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 little samba 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 through SMB. 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 doesn't even exist on RedHat distributions. Similarly, the "passwd chat" default will never work on any RedHat system. I wonder why RedHat doesn't change these defaults such that 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 arguments in 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 samba server, 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 make you 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.