Bug 1250110
| Summary: | search by users which don't have read rights for all attrs in search_attributes fails | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jan Cholasta <jcholast> |
| Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> |
| Status: | CLOSED ERRATA | QA Contact: | Namita Soman <nsoman> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.1 | CC: | ksiddiqu, pvoborni, rcritten, spoore |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ipa-4.4.0-1.el7 | Doc Type: | Bug Fix |
| Doc Text: |
An issue was fixed when searching in IPA didn't return all valid results if user didn't have read rights for all attributes in the query even though it was an "OR" filter.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-04 05:46:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jan Cholasta
2015-08-04 14:22:19 UTC
QE will need steps to verify this This BZ is a suggestion for a general solution of the related issues. It's out of scope of RHEL 7.2, moving to RHEL 7.3. Upstream ticket was fixed: https://fedorahosted.org/389/ticket/48275 https://fedorahosted.org/freeipa/ticket/5168 Petr, Can you provide steps to reproduce this? Thanks, Scott 1. have a user "fbar" which doesn't have rights to read everything (i.e. non-admin). 2. have object "foo" (let's assume other user) 3. "foo" has attribute(s) for which fbar doesn't have read rights, e.g., telephonenumber (for this example) 4. "foo" has a different attribute(s) which user can read, e.g. cn 5. have ldapsearch with filter (|(cn=foo)(telephonenumber=foo)) I.e. (|(true)(false) -> should return object 6. with fix it will return fbar, without fix it won't Epected is that it will because user can read the one for which it is evaluated as true. Basically this is a dup of bug 1316328 and related DS ticket https://fedorahosted.org/389/ticket/48275 both contains additional info. Verified. Version :: ipa-server-4.4.0-10.el7.x86_64 Results :: [root@vm1 ~]# echo "redhat" | ipa user-add testuser1 --first=first --last=last --phone=000-111-2222 --password ---------------------- Added user "testuser1" ---------------------- User login: testuser1 First name: first Last name: last Full name: first last Display name: first last Initials: fl Home directory: /home/testuser1 GECOS: first last Login shell: /bin/sh Principal name: testuser1 Principal alias: testuser1 Email address: testuser1 UID: 920400004 GID: 920400004 Telephone Number: 000-111-2222 Password: True Member of groups: ipausers Kerberos keys available: True [root@vm1 ~]# echo "redhat" | ipa user-add testuser2 --first=new --last=again --phone=333-444-5555 --password ---------------------- Added user "testuser2" ---------------------- User login: testuser2 First name: new Last name: again Full name: new again Display name: new again Initials: na Home directory: /home/testuser2 GECOS: new again Login shell: /bin/sh Principal name: testuser2 Principal alias: testuser2 Email address: testuser2 UID: 920400005 GID: 920400005 Telephone Number: 333-444-5555 Password: True Member of groups: ipausers Kerberos keys available: True [root@vm1 ~]# echo -e "redhat\nSecret123\nSecret123" | kinit testuser1 Password for testuser1: Password expired. You must change it now. Enter new password: Enter it again: [root@vm1 ~]# echo -e "redhat\nSecret123\nSecret123" | kinit testuser2 Password for testuser2: Password expired. You must change it now. Enter new password: Enter it again: [root@vm1 ~]# kdestroy -A [root@vm1 ~]# kinit admin Password for admin: [root@vm1 ~]# ldapmodify -x -D 'cn=Directory Manager' -w Secret123 -h localhost -p 389 dn: cn=users,cn=accounts,dc=example,dc=com changetype: modify add: aci aci: (targetattr = "telephoneNumber")(version 3.0;acl "Deny TelephoneNumber";deny (read)(userdn = "ldap:///uid=testuser1,cn=users,cn=accounts,dc=example,dc=com");) modifying entry "cn=users,cn=accounts,dc=example,dc=com" [root@vm1 ~]# ldapsearch -o ldif-wrap=no -x -D "cn=Directory Manager" -w Secret123 -b cn=users,cn=accounts,dc=example,dc=com "(objectclass=*)" aci|grep testuser aci: (targetattr = "telephoneNumber")(version 3.0;acl "Deny TelephoneNumber";deny (read)(userdn = "ldap:///uid=testuser1,cn=users,cn=accounts,dc=example,dc=com");) # testuser1, users, accounts, example.com dn: uid=testuser1,cn=users,cn=accounts,dc=example,dc=com # testuser2, users, accounts, example.com dn: uid=testuser2,cn=users,cn=accounts,dc=example,dc=com [root@vm1 ~]# ldapsearch -x -D "uid=testuser1,cn=users,cn=accounts,dc=example,dc=com" -w Secret123 -b cn=users,cn=accounts,dc=example,dc=com "(|(cn=new*)(telephone=333*))" dn cn telephone # extended LDIF # # LDAPv3 # base <cn=users,cn=accounts,dc=example,dc=com> with scope subtree # filter: (|(cn=new*)(telephone=333*)) # requesting: dn cn telephone # # testuser2, users, accounts, example.com dn: uid=testuser2,cn=users,cn=accounts,dc=example,dc=com cn: new again # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ########## reproduced failure on rhel7.1 also following exact commands from above ipa-server-4.1.0-18.el7_1.6.x86_64 [root@vm1 ~]# ldapsearch -x -D "uid=testuser1,cn=users,cn=accounts,dc=example,dc=com" -w Secret123 -b cn=users,cn=accounts,dc=example,dc=com "(|(cn=new*)(telephone=333*))" dn cn telephone # extended LDIF # # LDAPv3 # base <cn=users,cn=accounts,dc=example,dc=com> with scope subtree # filter: (|(cn=new*)(telephone=333*)) # requesting: dn cn telephone # # search result search: 2 result: 0 Success # numResponses: 1 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://rhn.redhat.com/errata/RHBA-2016-2404.html |