Bug 214463 - Add permission not handled correctly with userPassword attribute
Summary: Add permission not handled correctly with userPassword attribute
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Security - Access Control (ACL)
Version: 1.0.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 152373 240316
TreeView+ depends on / blocked
 
Reported: 2006-11-07 19:05 UTC by Nathan Kinder
Modified: 2015-12-07 17:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 17:00:51 UTC
Embargoed:


Attachments (Terms of Use)
CVS Diffs (1.26 KB, patch)
2006-11-07 19:05 UTC, Nathan Kinder
no flags Details | Diff

Description Nathan Kinder 2006-11-07 19:05:16 UTC
The "add" access right is not dealt with properly for the userPassword
attribute.  If you add the following ACI, anyone should be able to add a new entry:

(targetattr ="*")(version 3.0; acl "foo"; allow (add) (userdn = "ldap:///anyone");)

You will find that you get an error 50 when you attempt to add an entry
containing a userPassword attribute with the above ACI.  This is due to a
permissions check that occurs during an add operation to see if access to
userPassword is allowed before doing any password syntax checking.  The problem
is that it checks for the SLAPI_ACL_WRITE privilege instead of the SLAPI_ACL_ADD
privilege.  The SLAPI_ACL_WRITE privilege checks if the user is allowed to
perform a modify operation, not an add.

The attached diff fixes this issue.

Comment 1 Nathan Kinder 2006-11-07 19:05:16 UTC
Created attachment 140582 [details]
CVS Diffs

Comment 3 Nathan Kinder 2006-11-07 20:01:13 UTC
Checked into ldapserver (HEAD).  Thanks for the review Rich!

Checking in add.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/add.c,v  <--  add.c
new revision: 1.9; previous revision: 1.8
done


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