[SSSD] should not return "x" for password when there is no shadow information

Brian J. Murrell brian at interlinx.bc.ca
Tue Nov 3 05:49:59 UTC 2009


I was going to file this as a bug in Trac but it's not clear how one
creates an account there.

Witness the difference between nss_ldap and sssd (0.7.1) with regard to
the password in passwd map entries:

nss_ldap $ getent passwd brian
brian:*:1001:1001:Brian J. Murrell:/home/brian:/bin/bash

sssd $ getent passwd brian
brian:x:1001:1001:Brian J. Murrell:/home/brian:/bin/bash

Notice that sssd is reporting an "x" in the password field when nss_ldap
is reporting an "*".  The reason nss_ldap is reporting an "*" is because
there is no password information for this user in LDAP because this user
authenticates with kerberos.

The way nss_ldap knows whether to return an "x" or an "*" for the
password entry is based on whether the ldap entry has a shadowAccount
object class defined.  It all makes sense doesn't it?

So, sssd needs to be doing the same thing.  The reason is that the
pam_unix pam module's account personality does sanity checks on the
shadow information (password expired, going to expire?, etc.) when the
passwd entry says there is shadow information by specifying "x" in the
password field.  If there is no shadow information, which there is not
when there is no authentication data in ldap, then the sssd NSS module
should be returning something other than an "x".

I'd be happy to test a patch, or even do the hacking myself if somebody
wants to point me to where this "hardcoding" of the "x" is.

Cheers,
b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20091103/457f94a3/attachment.sig>


More information about the sssd-devel mailing list