RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1459946 - GetEffectiveRights gives false-negative with ACIs containing targetfilter
Summary: GetEffectiveRights gives false-negative with ACIs containing targetfilter
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.4
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Ludwig
QA Contact: Viktor Ashirov
Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-08 16:03 UTC by mreynolds
Modified: 2020-09-13 22:00 UTC (History)
4 users (show)

Fixed In Version: 389-ds-base-1.3.7.5-12
Doc Type: Bug Fix
Doc Text:
ACIs with the *targetfilter* keyword work correctly Previously, if an Access Control Instruction (ACI) in Directory Server used the "targetfilter" keyword, searches containing the *geteffective* rights control returned before the code was executed for template entries. Consequently, the *GetEffectireRights()* function could not determine the permissions when creating entries and returned false-negative results when verifying an ACI. With this update, Directory Server creates a template entry based on the provided *geteffective* attribute and verifies access to this template entry. As a result, ACIs in the mentioned scenario work correctly.
Clone Of:
Environment:
Last Closed: 2018-04-10 14:16:50 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 2337 0 None None None 2020-09-13 22:00:48 UTC
Red Hat Product Errata RHBA-2018:0811 0 None None None 2018-04-10 14:17:45 UTC

Description mreynolds 2017-06-08 16:03:33 UTC 
This bug is created as a clone of upstream ticket:
https://pagure.io/389-ds-base/issue/49278

#### Issue Description

Consider ACI:
```
aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl "permission:System: Add CA";allow (add) groupdn = "ldap:///cn=System: Add CA,cn=permissions,cn=pbac,<suffix>";)
```

The GetEffectiveRights control does not interpret this ACI as granting add
access to a user matching the `groupdn`.  This behaviour causes problems
in FreeIPA because it is impossible to properly test whether a non-admin
user is able to perform some actions.

#### Package Version and Platform

389-ds-base-1.3.5.17-3.fc25.x86_64

#### Steps to reproduce

1. Make an ACI like the above.
2. Query effective rights for a user who matches the ACI.
3. Observe that the GER control indicates that they do not have access.

#### Actual results

If the user is a member of the `groupdn`, the GetEffectiveRights control
indicates that the user does not have add access even when the user
does have add access (albeitit conditional on the `targetfilter` matching
the object to be added.)

#### Expected results

The GetEffectiveRights control should indicate that a user has entry-level
access (add or delete) even where the access is granted conditional on a
targetfilter.
Comment 1 Ludwig 2017-11-30 16:16:33 UTC 
fix for upstream ticket under review
Comment 2 Ludwig 2018-01-11 14:33:53 UTC 
upstream ticket fixed and committed
Comment 5 Ludwig 2018-01-25 11:31:40 UTC 
that just checks effective rights for an entry, but the bug is about a not existing entries defined by an objectclass. There are more details in this bug and the corresponding ticket.
see esopcially: https://pagure.io/389-ds-base/issue/49278#comment-480856
Comment 6 Akshay Adhikari 2018-02-09 07:38:04 UTC 
============================================================================ test session starts ============================================================================
platform linux -- Python 3.6.3, pytest-3.4.0, py-1.5.2, pluggy-0.6.0 -- /opt/rh/rh-python36/root/usr/bin/python3
cachedir: .pytest_cache
metadata: {'Python': '3.6.3', 'Platform': 'Linux-3.10.0-843.el7.x86_64-x86_64-with-redhat-7.5-Maipo', 'Packages': {'pytest': '3.4.0', 'py': '1.5.2', 'pluggy': '0.6.0'}, 'Plugins': {'metadata': '1.5.1', 'html': '1.16.1'}}
389-ds-base: 1.3.7.5-16.el7
nss: 3.34.0-4.el7
nspr: 4.17.0-1.el7
openldap: 2.4.44-13.el7
svrcore: 4.1.3-2.el7

rootdir: /export/tests, inifile:
plugins: metadata-1.5.1, html-1.16.1
collected 2 items                                                                                                                                                           

suites/get_effective_rights/acceptance_test.py::test_group_aci_entry_exists PASSED                                                                                    [ 50%]
suites/get_effective_rights/acceptance_test.py::test_group_aci_template_entry PASSED                                                                                  [100%]

------------------------------------------------------- generated xml file: /mnt/tests/rhds/tests/upstream/report.xml -------------------------------------------------------
------------------------------------------------------ generated html file: /mnt/tests/rhds/tests/upstream/report.html ------------------------------------------------------
========================================================================= 2 passed in 9.57 seconds ==========================================================================
Comment 10 errata-xmlrpc 2018-04-10 14:16:50 UTC 
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-2018:0811
Note You need to log in before you can comment on or make changes to this bug.