Bug 520151 - Error when modify userPassword with proxy user
Summary: Error when modify userPassword with proxy user
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: 389
Classification: Retired
Component: Security - Access Control (ACL)
Version: 1.1.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL: http://www.mail-archive.com/fedora-di...
Whiteboard:
: 634483 (view as bug list)
Depends On:
Blocks: 389_1.2.6 639035
TreeView+ depends on / blocked
 
Reported: 2009-08-28 16:07 UTC by Giovanni Mancuso
Modified: 2018-11-14 19:50 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-15 06:24:24 UTC


Attachments (Terms of Use)
0001-Bug-520151-Error-when-modifying-userPassword-with-pr.patch (3.02 KB, patch)
2010-03-24 20:45 UTC, Endi Sukma Dewata
rmeggins: review+
Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0866 normal SHIPPED_LIVE redhat-ds-base bug fix update 2011-06-15 06:24:00 UTC

Description Giovanni Mancuso 2009-08-28 16:07:07 UTC
Description of problem:

When i try to modify the userPassword attribute of one user with Proxy User, i have: "ldap_modify: Insufficient access"

Version-Release number of selected component:

I use Fedore DS 1.1.2

Steps to Reproduce:

1. Install 2 instance of DS (first and second)
2. Create a Proxy User in "second" instance (For Example:  uid=tproxy,cn=config
)
3. Set the sequent acl in "second" DS:

(targetattr = "*") (target = "ldap:///dc=example,dc=com";) (version
3.0;acl "proxy acl";allow (proxy)(userdn = "ldap:///uid=tproxy,cn=config";);)

(targetattr = "*") (version 3.0; acl "Administration User ACL";allow (all)(userdn
 = "ldap:///uid=ttestuser,cn=config");)

4. Create a new user in "first" DS (For Example uid=ttestuser,cn=config
)

5. Create a Db link in "first" that point to "second" using proxy user (uid=tproxy,cn=config)

6. Try to create a new user in new dblink (without userPassword attr): IT WORKS

7. Try to create a new user in new dblink with userPassword attr: IT FAILS

Additional info:

In Maillist archive there's more info: 
http://www.mail-archive.com/fedora-directory-users@redhat.com/msg09820.html

Comment 1 Rich Megginson 2009-09-26 02:41:42 UTC
This one is going to be tricky to fix.  The ADD and MODIFY code both check access to the userPassword attribute early in the processing, before the pre-op plugins are called.  This breaks proxied auth because it is the acl pre-op code in aclplugin_preop_common() that decodes the proxied auth information and sets the authorization used by the ACL code.

There are some options, in order of my preference:
1) make the acl_access_allowed code more robust, so that it can check for the proxied auth control and set the credentials if they have not already been checked and set.
2) change the add and modify code to call the acl check after the pre-op plugins have been called - the code will still have to put the clear text password in the unhashed pwd pseudo attr for the pre-op plugins to use
3) create a different plug-in point for access control plugins so that they are called as soon as the entire op has been read (including controls)

Comment 2 Endi Sukma Dewata 2010-03-24 20:45:18 UTC
Created attachment 402411 [details]
0001-Bug-520151-Error-when-modifying-userPassword-with-pr.patch

The acl_access_allowed() has been modified to call aclplugin_preop_common() which will initialize the aclpb. The aclplugin_preop_common() has been modified to check for the ACLPB_INITIALIZED flag to avoid re-initializing aclpb.

Comment 3 Rich Megginson 2010-03-24 21:35:55 UTC
To ssh://git.fedorahosted.org/git/389/ds.git
   eac3f15..742032c  master -> master

commit 742032c11f0dabbdc80ba204801c27c4cbe305a4
Author: Endi S. Dewata <edewata@redhat.com>
Date:   Sat Mar 20 21:03:59 2010 -0500
    Fix description: The acl_access_allowed() has been modified to
    call aclplugin_preop_common() which will initialize the aclpb.
    The aclplugin_preop_common() has been modified to check for the
    ACLPB_INITIALIZED flag to avoid re-initializing aclpb.
    Reviewed by: rmeggins (and pushed by)

Comment 4 Endi Sukma Dewata 2010-03-25 03:24:35 UTC
This bug can be tested using a single DS instance:

1. Prepare an instance with suffix dc=example,dc=com.
2. As directory manager add the following entries:

dn: cn=Manager,dc=example,dc=com
objectClass: inetOrgPerson
cn: Manager
sn: Manager
userPassword: manager

dn: cn=User,dc=example,dc=com
objectClass: inetOrgPerson
cn: User
sn: User
userPassword: user

3. As directory manager set the following ACL:

dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr="*")(version 3.0; acl "Manager"; allow (all) (userdn="ldap://
 /cn=Manager,dc=example,dc=com");)
aci: (targetattr="*")(version 3.0; acl "Proxy"; allow (proxy) (userdn="ldap://
 /cn=User,dc=example,dc=com");)
-

4. As regular user add the test entry:

/usr/lib/mozldap/ldapmodify -D "cn=User,dc=example,dc=com" -w user

dn: cn=Target,dc=example,dc=com
changetype:add
objectClass: inetOrgPerson
cn: Target
sn: Target
userPassword: target

This operation should fail.

5. As regular user with proxy authorization add the test entry:

/usr/lib/mozldap/ldapmodify -D "cn=User,dc=example,dc=com" -w user -Y "dn:cn=Manager,dc=example,dc=com"

dn: cn=Target,dc=example,dc=com
changetype:add
objectClass: inetOrgPerson
cn: Target
sn: Target
userPassword: target

This operation should work.

6. As regular user modify the test entry:

/usr/lib/mozldap/ldapmodify -D "cn=User,dc=example,dc=com" -w user

dn: cn=Target,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: target

This operation should fail.

7. As regular user with proxy authorization modify the test entry:

/usr/lib/mozldap/ldapmodify -D "cn=User,dc=example,dc=com" -w user -Y "dn:cn=Manager,dc=example,dc=com"

dn: cn=Target,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: target

This operation should work.

Comment 5 Marc Sauton 2010-09-23 16:38:18 UTC
I needed this fix for bz 634483 (a dup of this) for RHDS 8.2, and noticed although this blocker indicates "DS9.0 389_1.2.6", it does not seem to be in 389-ds-base-1.2.6-1.fc13.x86_64 (modify fails)

Comment 6 Rich Megginson 2010-09-23 16:44:14 UTC
(In reply to comment #5)
> I needed this fix for bz 634483 (a dup of this) for RHDS 8.2, and noticed
> although this blocker indicates "DS9.0 389_1.2.6", it does not seem to be in
> 389-ds-base-1.2.6-1.fc13.x86_64 (modify fails)

You tried the steps listed in https://bugzilla.redhat.com/show_bug.cgi?id=520151#c4 and it does not work?

Comment 7 Marc Sauton 2010-09-23 16:58:35 UTC
not exactly by the letter same as comment 4, but extremely similar for the feature like in bz 634483 comment 7 / https://bugzilla.redhat.com/show_bug.cgi?id=634483#c7
let me try the exact same as https://bugzilla.redhat.com/show_bug.cgi?id=520151#c4

Comment 8 Marc Sauton 2010-09-23 18:05:20 UTC
the test in
https://bugzilla.redhat.com/show_bug.cgi?id=520151#c4
works ok as expected with
389-ds-base-1.2.6-1.fc13.x86_64
so no worries here

I though bz 634483 was a dup of this report, but it is not, the aci are quite different in this report, bz 634483 has a target attribute userPassword, userattr attribute type and a USERDN bind type

Just somehow confused because:
the test from
https://bugzilla.redhat.com/show_bug.cgi?id=634483#c7
fails against 
389-ds-base-1.2.6-1.fc13.x86_64
and
redhat-ds-base-8.2.1-1.el5dsrv
after errata RHBA-2010-0692

but the same test from
https://bugzilla.redhat.com/show_bug.cgi?id=634483#c7
succeed if I apply the fix from
https://bugzilla.redhat.com/attachment.cgi?id=402411&action=edit
to
redhat-ds-base-8.2.1-1.el5dsrv

may be this should just continue into bz 634483 ...

Comment 9 Nathan Kinder 2010-10-04 22:14:27 UTC
*** Bug 634483 has been marked as a duplicate of this bug. ***

Comment 10 Jeremy Agee 2010-10-25 20:38:01 UTC
=== In Red Hat Customer Portal Case 00317678 ===
--- Comment by Agee, Jeremy on 10/25/2010 4:37 PM ---

I heard back from one of my cases and they can also confirm that the fix is working for them.  Looks like everything is fixed for the proxy user.

Comment 12 Marc Sauton 2011-05-06 21:27:55 UTC
I updated the hotfix for redhat-ds-base-8.2.4-2.el5dsrv.x86_64
for testing purpose:
http://10.14.7.221/rhds/bz.520151.aci.proxy.userPassword/

Comment 13 Marc Sauton 2011-05-09 23:58:47 UTC
due to popular demand, I updated the hotfix for redhat-ds-base-8.2.4-2.el5dsrv for both x86_64 and i386, for testing purposes, non official files and builds and details at:
http://10.14.7.221/rhds/bz.520151.aci.proxy.userPassword/

Comment 14 Sankar Ramalingam 2011-06-07 12:10:41 UTC
Successfully verified with ds8.2.5 build, errata #11223.

Comment 15 errata-xmlrpc 2011-06-15 06:24:24 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0866.html


Note You need to log in before you can comment on or make changes to this bug.