That was my first attempt to use git send-email; I wanted to have a
little extra explanation than the commit message, but that didn't happen.
In any case, this allows pam_userdb.so to use all the new crypt formats.
It's no longer limited to DES-crypted passwords and a measly 12 bits of
entropy on the salt. crypt will detect which password-hashing algorithm
was used to store the password via the salt (either the obsolete DES or
MD5, or tbcrypt or the new SHA256 and SHA512 based formats) and hash
accordingly. Without this patch, pam_userdb is out of the question for
pretty much any purpose.
I started playing with pam via google-authenticate yesterday, and one
thing I've wanted for a while is the ability to maintain a separate
database of passwords to authenticate the sudo command. The reason
being, I like to use a convenient password to get to root, but not allow
ssh logins using said password. (or preferably, any password at all...)
However disabling password logins via ssh is not always an option on
servers that other admins access as well. And some of the servers have
older software stacks, where sshd can't disable passwords on a per-user
basis. So I was hoping there was a nice simple way to set a sudo
password with a minimal (preferably no) requirement for additional software
or software upgrades, and lock my regular password.
I pretty quickly found pam_userdb, which seemed exactly what I needed,
but try as I might, I just couldn't get crypted passwords working, so I
eventually looked at the source and found this problem. The fix appears
to be working just fine on my laptop.
One thing I'm not exactly clear on is how crypt() deals with the boundary
conditions on the salt, and couldn't find anything in the documentation in
this regard. However, the worst that could happen with a runaway
boundary condition is a read access error, as it's a (const char *).
My educated guess would be that it would test whether the first character
is $ or not, and if not take the first two characters as the salt to
DES-crypt. If it is, I'm guessing it just looks for two more $...
probably also verifying that the intervening characters are valid base64
(./) characters.
In any case, the data in the password database should be pretty
trustworthy. If it's not, you've _probably_ got bigger problems than
people trying to exploit calls to crypt.
Best,
Leon
