https://bugzilla.redhat.com/show_bug.cgi?id=457260 Resolves: bug 457260Bug Description: The dnaFilter configuration setting is supposed to be applied against an entry to determine if a particular managed range applies to the entry.
I have found that it is not used properly. Here's what I have observed: - Configure two managed ranges. One is for the uidNumber for"objectclass=posixAccount" entries. The second is for the gidNumber for
"objectclass=posixGroup" entries. - Add a new "posixAccount" entry without specifying a "uidNumber" or "gidNumber" attribute value.The user will be successfully added, and both "uidNumber" and "gidNumber" values will be generated for the new entry, even though the configuration states that
only the "uidNumber" should be generated. Reviewed by: ??? Files: see diff Branch: HEADFix Description: The problem is related to the way we load the dnaFilter value from the configuration entries. Our cached configuration entries in the DNA plug-in contain a string representation of the filter in addition to a Slapi_Filter based off of that string. The problem is that we call slapi_str2filter() to create the Slapi_Filter, but we store the pointer to it in our char * pointer
that is supposed to be the filter string.This fix simply stores the Slapi_Filter in the proper member of the configEntry struct. With this fix, the test in comment#1 properly rejects adding a new
"posixAccount" with no "gidNumber" attribute specified. If one explicitlyspecifies a "gidNumber" when adding the entry, the entry is added successfully,
and the "uidNumber" value is generated by the DNA plug-in. Platforms tested: Fedora 8 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=313010&action=diff
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
