[Fedora-directory-users] Question about ACI

Mon Dec 10 17:48:32 UTC 2007

Couple things here.  First, avoid deny rules if at all possible - deny
rules always take precedence, so you can *never* override a deny rule
with something to allow access that has been denied elsewhere.

Second, I think you are misunderstanding how ldap:///self works.
ldap:///self basically says "These permissions are granted on the
targetted entry if I bind to the server as that target entry".  In your
case, what your deny rule is saying is that if I bind as user1, I can't
read, write, or even search for the user1 entry, and as a deny rule, you
can't create any other rule to ever allow user1 to see his own entry. 

So, you've created a rule that says anyone can read/write/search to
anything under ou=serviceaccounts, *except* user1 can't
read/write/search on his own entry.

BTW, this seems like a really bad idea.  Forget about ACI's and
implementation for the moment - conceptually, what are you trying to do?
Who should be able to do what?  Are you saying you want anyone except
user1 to be able to have full access to anything under
ou=serviceaccounts?  

To define your access controls, you should really figure out who you
want to do what, then define aci's for each thing you want to allow,
such that they only *allow* just what you need, so you don't need any
kind of deny rules.

If you want to, for example, allow any user to edit any part of just
their own record, put something like the following on the
ou=serviceaccounts entry:

aci:
 (targetattr = "*")
 (version 3.0;
 acl "default aci for service accounts";
 allow (all)
 (userdn=ldap:///self) 
 ;)

This says that if I bind as a user under ou=serviceaccounts, I have full
read/write/search access to the entry I bound as (i.e. my account).
However, I'd recommend making even that more restrictive (for example,
if all they really need to write to is their password, create one aci to
allow them to read/search all attributes except the userpassword, and
one to allow write to the userpassword with userdn of ldap:///self),
etc.  If you want all users to read other users entries, create another
aci that allows search/read access to ldap:///anyone (and at least make
it targetattr!="userpassword"), and so on..

 - Jeff

________________________________

From: fedora-directory-users-bounces at redhat.com
[mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Chun Tat
David Chu
Sent: Monday, December 10, 2007 11:37 AM
To: fedora-directory-users at redhat.com
Subject: Re: [Fedora-directory-users] Question about ACI

Hi guys,

Please see below for my original question.

I spend a little more time reading "Chapter 6 - Managing Access Control"
from the RH Administrator Guide.  At first, I thought it was my
placement of ACI that was wrong, but it seems like that's not the case
from what I read.  The book stated that "The precedence rule that
applies is that ACIs that deny access take precedence over ACIs that
allow access."  If my root allows everything and then my leaf denies
everything then I don't see why the add operation that I mentioned below
should work. 

Let me clear up a little more in case there's any confusion.  The
ou=serviceaccounts and cn=user1 entry is created by the "cn=Directory
Manager" user.  In my test, the root (ou=serviceaccounts), I specified
an ACI that allows all user to do anything.  In my leaf (cn=user1), I
specified an ACI that denies everything for user1 by defining the bind
rule as (ldap:///self). 

When I logged in as user1, I'm able to add entry in the cn=user1
context.  I am not sure why because I thought that user1 shouldn't have
any privilege to do anything due to my specified ACI.

Any idea?  Am I missing some obvious? 

Thanks!

David

On Dec 7, 2007 6:28 PM, Chun Tat David Chu <beyonddc.storage at gmail.com>
wrote:

	Hi guys,

	I am trying to create an organizational unit and an user with
ACI, but it looks like my ACI is not defined correctly.
	Below is my ldif.

	dn: ou=serviceaccounts,dc=test,dc=example,dc=com
	changetype: add 
	objectclass: top
	objectclass: organizationalunit
	aci:
	 (targetattr = "*")
	 (version 3.0;
	 acl "default aci for service accounts";
	 allow (all)
	 (userdn="ldap:///anyone") 
	 ;)

	dn: cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com
	changetype: add
	objectclass: top
	objectclass: person
	sn: tscei.obs
	userPassword: testing123
	description: This is a test
	aci:
	 (targetattr = "*")
	 (version 3.0;
	 acl "user1";
	 deny (all)
	 (userdn="ldap:///self")
	 ;)

	I create an organizational unit that allows all users to modify
it, then I create user1 that denies everything. 
	I then use the below LDIF to perform a LDAP add operation.

	dn:
cn=testing123,cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com
	changetype: add
	objectclass: top
	objectclass: room

	I use this ldapmodify command to perform the add operation 
	ldapmodify -h hostname -p 1389 -D
"cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com" -w testing123 -f
my_test.ldif -x

	The add operation succeeded unexpectedly.  The result that I'm
looking for should be not enough privilege to perform add operation. 

	Anyone knows what's wrong with my ACI setup?

	Thanks!

	David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20071210/a781480f/attachment.html>