[SSSD] memberUID corruption handling

Simo Sorce simo at redhat.com
Tue Nov 8 14:32:47 UTC 2011


On Tue, 2011-11-08 at 10:05 +0100, Jakub Hrozek wrote:
> On Mon, Nov 07, 2011 at 03:13:35PM -0500, Stephen Gallagher wrote:
> > I've noticed lately on a couple of LDAP environments (all of which
> > having been converted at some point in the past from NIS) that there is
> > a tendency for bad conversion scripts to sometimes leave around groups
> > with improperly formatted memberUID values.
> > 
> > For example:
> > 
> > dn: cn=groupA,ou=Groups,dc=example,dc=com
> > objectClass: posixGroup
> > ...
> > memberUID: user1,user2,user3
> > 
> > 
> > Now, the standards-compliant approach here would be to just treat
> > 'user1,user2,user3' as a single group entry (that except on the most
> > psychotic of systems would never match an actual username).
> > 
> > However, it's well within our power in SSSD to handle this more
> > gracefully, by parsing the commas ourselves. My question is, is this
> > something we should do, or should we continue treating this as useless
> > data and use it to encourage admins to fix their systems?
> > 
> > This *has* caused negative behavior in the SSSD in the past
> > (specifically, there was a bug in some older versions of LDB that caused
> > it to be unable to perform a reindex on DNs that contained an escaped
> > comma, thus rendering SSSD incapable of safely upgrading to newer
> > versions).
> 
> I would vote for skipping (and verbosely logging) an entry like this. It's
> just broken.
> 
> I'm afraid that if we tried to handle this case gracefully, admins would
> not be forced to fix this entry and would go "eh, sssd works, why bother".
> 
> There may be environments where the LDAP server is administered by
> different set of admins than SSSD configurations are, procedures are in
> place etc, which may cause fixing the directory hard, but we need to
> draw the line somewhere.
> 
> Also, I ran a quick test with nss-pam-ldapd and they would punt on this
> memberuid as well.

Yeah I was going to bring up the nss_ldap behavior as well, which is to
*not* handle this gracefully.

I think we should not care about bad entries, nothing recognizes them
anyway and it would be a violation of the spec to do so.

If LDB had issues handling DNs with ',' embedded we need to fix that
bug, because technically usernames or group names are allowed to have
',' in the name. So we just must be able to support that.

Simo.

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




More information about the sssd-devel mailing list