https://bugzilla.redhat.com/show_bug.cgi?id=781208
Description of problem: Cannot search user list by manager name using user-find --manager. More in Additional Info section. Version-Release number of selected component (if applicable): This test was run on Fedora 16 with latest(?) freeipa rpms. # rpm -qa|grep freeipa freeipa-server-2.1.4-3.fc16.x86_64 freeipa-client-2.1.4-3.fc16.x86_64 freeipa-admintools-2.1.4-3.fc16.x86_64 freeipa-python-2.1.4-3.fc16.x86_64 freeipa-server-selinux-2.1.4-3.fc16.x86_64 How reproducible: always? Steps to Reproduce: 1. ipa user-add --first=first --last=last testmanager 2. ipa user-add --first=first --last=last testuser 3. ipa user-mod testuser --manager=testmanager <should see "Manager: testmanager" in output here> 4. ipa user-find testuser --manager=testmanager Actual results: # ipa user-find testuser --manager=testmanager --------------- 0 users matched --------------- ---------------------------- Number of entries returned 0 ---------------------------- Expected results: Should return 1 match for testuser. Additional info: I'm not sure if this is intentional or even matters here but, thought I would note also that in my testing the following seems to match all users: ipa user-find --manager="" Full (sanitized) output from failure tests below: # ipa user-add --first=first --last=last testmanager ------------------------ Added user "testmanager" ------------------------ User login: testmanager First name: first Last name: last Full name: first last Display name: first last Initials: fl Home directory: /home/testmanager GECOS field: first last Login shell: /bin/sh Kerberos principal: testmanager@TESTRELM UID: 1798000033 GID: 1798000033 Keytab: False Password: False # ipa user-add --first=first --last=last testuser --------------------- Added user "testuser" --------------------- User login: testuser First name: first Last name: last Full name: first last Display name: first last Initials: fl Home directory: /home/testuser GECOS field: first last Login shell: /bin/sh Kerberos principal: testuser@TESTRELM UID: 1798000034 GID: 1798000034 Keytab: False Password: False # ipa user-mod testuser --manager=testmanager ------------------------ Modified user "testuser" ------------------------ User login: testuser First name: first Last name: last Home directory: /home/testuser Login shell: /bin/sh UID: 1798000034 GID: 1798000034 Manager: testmanager Account disabled: False Keytab: False Password: False Member of groups: ipausers # ipa user-find testuser --manager=testmanager --------------- 0 users matched --------------- ---------------------------- Number of entries returned 0 ----------------------------
It might be related to the DN cleanup.
Assuming DN cleanup gets in this will either be solved, or easier solvable. If not we might have to defer it more.
I think this will be solved by checking the syntax of attributes when creating our search filters. If the attribute is a dn then we'll generate the appropriate search value. I think this is probably unrelated to the DN work as the support is already available.
The manager LDAP attribute is a dn pointing inside the user container. When passed on the command it is typically a bare user uid. The search filter will only succeed if the bare uid is converted to a full dn because that is what is stored in the value for the manager attribute.
The search failure is solved by calling _normalize_manager() which does the conversion to a dn (if not already a dn).
It feels like this type of conversion should be performed in the pre callback which allows one to modify the filter. But when the pre callback is invoked it's complex string with the manager attribute already inserted. This is because the LDAPSearch.execute() method processes the options dict and constructs a filter component for each key/value in the options dict prior to invoking the pre callback. If we wanted to modify the manager value in the filter in the pre callback we would have to decompose the filter string, perform dn checking and then reassemble the filter. It's much cleaner to perform the dn operations on the manager value before it gets embedded into what otherwise might be a very complex filter. This is the reason why the normalization is perfored in the execute method as opposed to the pre callback. Other classes do similar things in their execute methods as opposed to their callbacks's, selinuxusermap_find is one example.
patch submitted
freeipa-jdennis-0081-ipa-user-find-manager-does-not-find-matches.patch
This should be applied to both master and 3.0
master: 557b260[[BR]] ipa-3-0: cbfe062
Moving closed RC1 tickets to Beta 3.
Metadata Update from @mkosek: - Issue assigned to jdennis - Issue set to the milestone: FreeIPA 3.0 Beta 3
Login to comment on this ticket.