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 1420960 - Need a way for plugin to modify the request during ADD op. after the ACIs are evaluated
Summary: Need a way for plugin to modify the request during ADD op. after the ACIs are...
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
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: wibrown@redhat.com
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-10 00:31 UTC by Noriko Hosoi
Modified: 2020-09-13 21:13 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.3.6.1-3.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 21:14:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1256 0 None None None 2020-09-13 21:13:19 UTC
Red Hat Product Errata RHBA-2017:2086 0 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2017-08-01 18:37:38 UTC

Description Noriko Hosoi 2017-02-10 00:31:22 UTC 
Description of problem:
 IPA has a plugin which replaces a known value (ipaUniqueID=autogenerate) with a randomly generated UUID (ipaUniqueID=autogenerate). It currently executes in preoperation and internalpreoperation.

In the case of preoperation, the access controls are evaluated *after* the UUID plugin makes the change. This means that the access controls are useless for any attribute randomly generated by the UUID plugin. You should be able to create an ACI that restricts access to the known value only.

Here is a real world case. To allow users to create tokens, we have an ACI like this:

aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter
"(objectClass=ipaToken)")(version 3.0; acl "Users can create

self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and
userattr = "managedBy#SELFDN";)

The problem is that this permits a user to create an entry with any value. If ACIs were evaluated before the UUID plugin and not afterward, we could use this ACI:

aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
$SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl
"Users can create self-managed tokens"; allow (add) userattr =
"ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)

For add operations, ACIs are currently evaluated after bepreop but before betxnpreop. Unfortunately, we can't change DN/ipaTokenUniqueID in betxnpreop. For modify operations, the ACIs are currently evaluated before bepreop. One possible solution would be to move the add operation behavior to be the same as the modify operation.
Comment 2 Simon Pichugin 2017-05-31 17:36:53 UTC 
After a small investigation, I have a question regarding verification steps.

Is there an easy way to verify the BZ with the user operations?

Or the only way to verify it is to run ACI (and plugins) test suites for a check for regressions and also to do the sanity testing?
Comment 3 wibrown@redhat.com 2017-05-31 23:49:52 UTC 
I have *no idea* if there is an easy way to test. I would test aci's still evaluate correctly, no resource leaks etc. It was IPA who raised this request so maybe they know what do here .... ? Sorry I can't help more, I wish I could.
Comment 4 Simon Pichugin 2017-06-02 09:32:31 UTC 
According to William's commentary above and source code investigation, we can't reproduce the problem properly. The change is about a change of internal operations order.
Through our CI we check it for regressions. Also sanity testing.

[root@qeos-67 ds]# py.test -v dirsrvtests/tests/suites/acl/
=================== test session starts ===================
platform linux2 -- Python 2.7.5, pytest-3.1.1, py-1.4.33, pluggy-0.4.0 -- /usr/bin/python
cachedir: .cache
metadata: {'Python': '2.7.5', 'Platform': 'Linux-3.10.0-671.el7.x86_64-x86_64-with-redhat-7.4-Maipo', 'Packages': {'py': '1.4.33', 'pytest': '3.1.1', 'pluggy': '0.4.0'}, 'Plugins': {'beakerlib': '0.7.1', 'html': '1.14.2', 'cov': '2.5.1', 'metadata': '1.5.0'}}
DS build: 1.3.6.1
389-ds-base: 1.3.6.1-15.el7
nss: 3.28.4-8.el7
nspr: 4.13.1-1.0.el7_3
openldap: 2.4.44-4.el7
svrcore: 4.1.3-2.el7

rootdir: /mnt/tests/rhds/tests/upstream/ds, inifile:
plugins: metadata-1.5.0, html-1.14.2, cov-2.5.1, beakerlib-0.7.1
collected 26 items

dirsrvtests/tests/suites/acl/acl_test.py::test_aci_attr_subtype_targetattr[lang-ja] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_aci_attr_subtype_targetattr[binary] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_aci_attr_subtype_targetattr[phonetic] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_mode_default_add_deny PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_mode_default_delete_deny PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_staging_prod[0-cn=staged user,dc=example,dc=com-cn=accounts,dc=example,dc=com-False] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_staging_prod[1-cn=staged user,dc=example,dc=com-cn=accounts,dc=example,dc=com-False] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_staging_prod[2-cn=staged user,dc=example,dc=com-cn=bad*,dc=example,dc=com-True] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_staging_prod[3-cn=st*,dc=example,dc=com-cn=accounts,dc=example,dc=com-False] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_staging_prod[4-cn=bad*,dc=example,dc=com-cn=accounts,dc=example,dc=com-True] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_staging_prod[5-cn=st*,dc=example,dc=com-cn=ac*,dc=example,dc=com-False] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_staging_prod[6-None-cn=ac*,dc=example,dc=com-False] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_staging_prod[7-cn=st*,dc=example,dc=com-None-False] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_staging_prod[8-None-None-False] PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_staging_prod_9 PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_prod_staging PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_check_repl_M2_to_M1 PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_moddn_staging_prod_except PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_mode_default_ger_no_moddn PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_mode_default_ger_with_moddn PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_mode_switch_default_to_legacy PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_mode_legacy_ger_no_moddn1 PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_mode_legacy_ger_no_moddn2 PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_mode_legacy_ger_with_moddn PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_rdn_write_get_ger PASSED
dirsrvtests/tests/suites/acl/acl_test.py::test_rdn_write_modrdn_anonymous PASSED

=================== 26 passed in 21.97 seconds ===================
Comment 5 errata-xmlrpc 2017-08-01 21:14:10 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-2017:2086
Note You need to log in before you can comment on or make changes to this bug.