Bug 521088

Summary: DNA should check ACLs before getting a value from the range
Product: [Retired] 389 Reporter: Nathan Kinder <nkinder>
Component: Server - DNA Plug-inAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.2.1CC: amsharma, jgalipea
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 16:54:37 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:
Bug Depends On:    
Bug Blocks: 639035    
Attachments:
Description Flags
Patch nhosoi: review+

Description Nathan Kinder 2009-09-03 15:17:30 UTC 
The DNA plug-in gets a value from the range at the pre-op stage, which means that the operation can fail at a later point.  There is no easy way to return the valeu to the range in the current implementation since a range is contiguous and other threads may have assigned later values. (see bug 510182 for details).

At a minimum, it would be good to have DNA call the ACL plug-in to ensure that the operation is not going to fail due to an insufficient access error, which is likely the most common cause of the operation failing.
Comment 2 Nathan Kinder 2010-11-01 19:44:09 UTC 
Created attachment 456975 [details]
Patch
Comment 3 Nathan Kinder 2010-11-01 20:14:12 UTC 
Pushed to master.  Thanks to Noriko for her review!

Counting objects: 13, done.
Delta compression using 2 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.08 KiB, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   abdf136..fe6f8f2  master -> master
Comment 6 Amita Sharma 2011-07-11 14:41:39 UTC 
[root@testvm scripts]# ldapadd -x -p 1389 -h localhost -D "cn=Directory Manager" -w Secret123 << EOF
> dn: cn=Account UIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> objectClass: top
> objectClass: extensibleObject
> cn: Account UIDs
> dnatype: uidNumber
> dnamaxvalue: 1010
> dnamagicregen: 0
> dnafilter: (objectclass=posixAccount)
> dnascope: dc=example,dc=com
> dnanextvalue: 1001
> EOF
adding new entry "cn=Account UIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config"

ldapadd -x -h localhost -p 1389 -D "cn=Directory Manager" -w Secret123  << EOF
dn: uid=amsharma1,ou=people,dc=example,dc=com
cn: ams
sn: ams
givenname: ams
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: ams
mail: ams
userpassword: amsamsams
EOF

- Bind as your test user and attempt to add a new "posixAccount" entry.  Be
sure to use the DNA magic value for the "uidNumber"attribute value.  The ADD
operation should be rejected by the default ACIs.
ldapadd -x -h localhost -p 1389 -D "uid=amsharma1,ou=people,dc=example,dc=com" -w amsamsams  << EOF
dn: uid=ttest,dc=example,dc=com
gidNumber: 12
uid: ttest
givenName: test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
objectClass: mepOriginEntry
homeDirectory: /home
sn: test
cn: test test

[root@testvm scripts]# ldapadd -x -h localhost -p 1389 -D "uid=amsharma1,ou=people,dc=example,dc=com" -w amsamsams  << EOF
> dn: uid=ttest,dc=example,dc=com
> gidNumber: 12
> uid: ttest
> givenName: test
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetorgperson
> objectClass: posixAccount
> objectClass: mepOriginEntry
> homeDirectory: /home
> sn: test
> cn: test test
> EOF
adding new entry "uid=ttest,dc=example,dc=com"
ldap_add: Object class violation (65)
	additional info: missing attribute "uidNumber" required by object class "posixAccount"



- Bind as Directory Manager and add a new "posixAcount" entry.  Be sure to use
the DNA magic value for the "uidNumber"attribute value.  The ADD should
succeed.
ldapadd -x -h localhost -p 1389 -D "cn=Directory Manager" -w Secret123  << EOF
dn: uid=ttest,dc=example,dc=com
gidNumber: 12
uid: ttest
givenName: test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
objectClass: mepOriginEntry
homeDirectory: /home
sn: test
cn: test test

[root@testvm scripts]# ldapadd -x -h localhost -p 1389 -D "cn=Directory Manager" -w Secret123  << EOF
> dn: uid=ttest,dc=example,dc=com
> gidNumber: 12
> uid: ttest
> givenName: test
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetorgperson
> objectClass: posixAccount
> objectClass: mepOriginEntry
> homeDirectory: /home
> sn: test
> cn: test test
> EOF
adding new entry "uid=ttest,dc=example,dc=com"


The failed ADD should not consume a value from the DNA range.  You can check
this by looking at the "uidNumber" value that is assigned to the user added by
Directory Manager, or you can look at the DNA config entry to see if
dnaNextValue was incremented from the failed ADD.

# ttest, example.com
dn: uid=ttest,dc=example,dc=com
gidNumber: 12
uid: ttest
givenName: test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
objectClass: mepOriginEntry
homeDirectory: /home
sn: test
cn: test test
uidNumber: 1001

Hence VERFIED