[SSSD] [PATCH] Make the password field configurable in NSS

Simo Sorce ssorce at redhat.com
Tue Nov 17 14:02:21 UTC 2009


On Mon, 2009-11-16 at 20:21 -0500, Brian J. Murrell wrote:
> On Tue, 2009-11-17 at 01:01 +0100, Jakub Hrozek wrote: 
> > Per the discussion on sssd-devel list, nss_sss should not return a
> > hardcoded value but this should rather be configurable to allow whatever
> > the OS or distribution thinks is the best for the particular case.
> 
> I disagree with the nature of this fix.  The decision as to what to
> return in the password field of the passwd map is not really a
> per-distribution issue.  Even within the same distribution, different
> configurations should have different results and altering the
> configuration will change the results.
> 
> With regard to the "x" as the password field, the rules/conditions are
> quite clear.  If there is shadow information available for the account,
> the password field should be set to an "x".
> 
> So in the case of an /etc/passwd and /etc/shadow, the password field
> in /etc/passwd should be "x" and sssd should return that if it were
> proxying for /etc/passwd (which I'm not even sure if it does).
> 
> In the case of LDAP, if the entry for the user had shadow information
> available (i.e. it has the shadowAccount object class in the entry) then
> the password field should be returned as "x" and if it does NOT have
> that object class, then the password field should return something else.
> Probably, if the ldap entry has an otherwise viable password entry, it
> should be returned, but if it does not, returning "*" seems to be
> acceptable given that if the LDAP entry does not have a password, then
> something else (i.e. kerberos) will be getting used.
> 
> So as you can see what to return is much more local configuration
> dependent than distro-policy.
> 
> One could argue that the sysadmin should set the value to be returned to
> something reasonable for his configuration, but what about a mixed mode
> even, where some users are authenticated out of LDAP and some out of
> kerberos?  Then even a single configuration item is not possible.

We don't support shadow maps so we never return shadow information
currently. So I don't see the need for this to be conditional at this
stage.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list