Bug 1636061
| Summary: | NPE when listing available LDAP groups using objectclass=* group search filter | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Operations Network | Reporter: | Filip Brychta <fbrychta> | ||||
| Component: | Core Server | Assignee: | Josejulio Martínez <jmartine> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Filip Brychta <fbrychta> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | JON 3.3.9, JON 3.3.10 | CC: | jmartine, loleary, spinder | ||||
| Target Milestone: | ER01 | Keywords: | Triaged | ||||
| Target Release: | JON 3.3.12 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-06-27 15:58:45 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
The problem here is that the query (objectclass=*) is returning element that don't have the "cn" attribute. e.g. # jboss.org dn: dc=jboss,dc=org dc: jboss objectClass: top objectClass: domain # Users, jboss.org dn: ou=Users,dc=jboss,dc=org objectClass: organizationalUnit ou: Users We could ignore elements when cn == null or use the "dn" in these cases. The second option would look like: dc=jboss,dc=org ldapadm ou=Users,dc=jboss,dc=org jonqa jonqa2 ... @Josejulio, what is CN being used for here? Display only? If so, then agreed, DN should be what we display for matches from the query if a CN is not available. But you will need to confirm that CN is not being used elsewhere. Considering that there was an assumption that every LDAP entry would have a common name, I am wondering if the same assumption was made elsewhere. If so, by allowing an entry without a CN, a similar failure could occur later on when performing the actual mapping or storing the mapping in the database. Is being used for the "id" and "name". That find method builds a map, that seems to be used everywhere else in the process, but is possible that somewhere else the process is duplicated. It would be way safer to just ignore null cn, but I could do a more complete test if you think is worth to have all the entries. Although I think we should handle this correctly, my vote is for ignoring/dropping entries without a CN. This is what QEs expected results would indicate... well, except that it says "Proper error." I don't really think an error is necessary if at least 1 entry with a CN was returned. Then our code logic remains the same. However, the same review will be necessary as there could be other places that we are executing this query and then relying on CN. You can probably track those easier as it should only apply to anything that uses this LDAP criteria configuration element. commit f7e9f410ac9cf6a7620d02abc5daab083fa9b108
Author: Josejulio Martínez <finwemartinez>
Date: Mon Apr 8 16:15:39 2019 -0500
Bug 1636061 - Ignore groups with null cn (#366)
* Bug 1636061 - Ignore groups with null cn
* Bug 1636061 - Check if content of nameAttribute is not null
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:1631 |
Created attachment 1490472 [details] server log with exception Description of problem: NPE is thrown when listing available LDAP groups using too generic objectclass=* group search filter on Edit Role page Version-Release number of selected component (if applicable): JON3.3.11.CR01 and earlier How reproducible: Always Steps to Reproduce: 1. set up openLDAP following way (or use web.bc.jonqe.lab.eng.bos.redhat.com): ldapsearch -h web.bc.jonqe.lab.eng.bos.redhat.com -p 10389 -z 0 -x -W -D "cn=ldapadm,dc=jboss,dc=org" -b "dc=jboss,dc=org" "objectclass=*" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=jboss,dc=org> with scope subtree # filter: objectclass=* # requesting: ALL # # jboss.org dn: dc=jboss,dc=org dc: jboss objectClass: top objectClass: domain # ldapadm, jboss.org dn: cn=ldapadm,dc=jboss,dc=org objectClass: organizationalRole cn: ldapadm description: LDAP Manager # Users, jboss.org dn: ou=Users,dc=jboss,dc=org objectClass: organizationalUnit ou: Users # jonqa, Users, jboss.org dn: uid=jonqa,ou=Users,dc=jboss,dc=org objectClass: top objectClass: account objectClass: posixAccount objectClass: shadowAccount cn: jonqa uid: jonqa uidNumber: 16859 gidNumber: 100 homeDirectory: /home/jonqa loginShell: /bin/bash shadowLastChange: 0 shadowMax: 0 shadowWarning: 0 userPassword:: e1NTSEF9MkwxSFg5UFNRTU55Qll6Zk94d0JEMHBpckNjcXpCTUg= # jonqa2, Users, jboss.org dn: uid=jonqa2,ou=Users,dc=jboss,dc=org objectClass: top objectClass: account objectClass: posixAccount objectClass: shadowAccount cn: jonqa2 uid: jonqa2 uidNumber: 16860 gidNumber: 100 homeDirectory: /home/jonqa2 loginShell: /bin/bash shadowLastChange: 0 shadowMax: 0 shadowWarning: 0 userPassword:: e1NTSEF9YUtaWVJwNE1BZjNRaXN5WlJ2VkhRVlFOcW04aUFEQlg= # Groups, jboss.org dn: ou=Groups,dc=jboss,dc=org objectClass: organizationalUnit ou: Groups # jon, Groups, jboss.org dn: cn=jon,ou=Groups,dc=jboss,dc=org objectClass: top objectClass: posixGroup gidNumber: 100 cn: jon memberUid: jonqa # other, Groups, jboss.org dn: cn=other,ou=Groups,dc=jboss,dc=org objectClass: top objectClass: posixGroup gidNumber: 10000 cn: other memberUid: otherGroupMyTest # noGroupMyTest, Users, jboss.org dn: uid=noGroupMyTest,ou=Users,dc=jboss,dc=org objectClass: top objectClass: account objectClass: posixAccount objectClass: shadowAccount cn: noGroupMyTest uid: noGroupMyTest uidNumber: 16861 gidNumber: 1 homeDirectory: /home/myTest loginShell: /bin/bash shadowLastChange: 0 shadowMax: 0 shadowWarning: 0 userPassword:: e1NTSEF9Z2NzTHo1dGNobCtzVDBBYWFGYTBPTExlQzBjWjNzMXE= # otherGroupMyTest, Users, jboss.org dn: uid=otherGroupMyTest,ou=Users,dc=jboss,dc=org objectClass: top objectClass: account objectClass: posixAccount objectClass: shadowAccount cn: otherGroupMyTest uid: otherGroupMyTest uidNumber: 16862 gidNumber: 10000 homeDirectory: /home/otherGroupMyTest loginShell: /bin/bash shadowLastChange: 0 shadowMax: 0 shadowWarning: 0 userPassword:: e1NTSEF9ZzJPOC81Tkh4UUEzeFFTWUFtbDJvZ0p0a1NNdkVwM3M= # search result search: 2 result: 0 Success # numResponses: 11 # numEntries: 10 2. enable LDAP in Administration->System Settings 3. fill following properties: Search Base :dc=jboss,dc=org Username: cn=ldapadm,dc=jboss,dc=org Password: Group Search Filter: objectclass=* Group Member Filter: memberuid Login Property: uid LDAP URL: ldap://web.bc.jonqe.lab.eng.bos.redhat.com:10389 4. Save 5. Go to Administration->Roles->All Resources Roles->LDAP Groups Actual results: Failed to load LDAP groups available for role. And following NPE in server.log: Caused by: java.lang.NullPointerException at org.rhq.enterprise.server.resource.group.LdapGroupManagerBean.executeGroupSearch(LdapGroupManagerBean.java:662) [rhq-server.jar:4.12.0.JON330GA-redhat-10] at org.rhq.enterprise.server.resource.group.LdapGroupManagerBean.buildGroup(LdapGroupManagerBean.java:561) [rhq-server.jar:4.12.0.JON330GA-redhat-10] at org.rhq.enterprise.server.resource.group.LdapGroupManagerBean.findAvailableGroups(LdapGroupManagerBean.java:127) [rhq-server.jar:4.12.0.JON330GA-redhat-10] Expected results: Proper error Additional info: Full stacktrace in attachment Not a regression