<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3199" name=GENERATOR></HEAD>
<BODY>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007></SPAN> </DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff size=2>Second, I think
you are misunderstanding how <A href="ldap:///self">ldap:///self</A>
works. <A href="ldap:///self">ldap:///self</A> 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.</FONT> </SPAN></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff size=2>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?
</FONT></SPAN></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff size=2>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:</FONT></SPAN></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff size=2><FONT
face="Times New Roman" color=#000000 size=3>aci:<BR> (targetattr =
"*")<BR> (version 3.0;<BR> acl "default aci for service
accounts";<BR> allow (all)<BR> (userdn=<A
href="ldap:///self">ldap:///self</A>)
<BR> ;)</FONT><BR></FONT></SPAN></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff size=2>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).</FONT></SPAN></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff size=2>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 <A href="ldap:///self">ldap:///self</A>), etc.
If you want all users to read other users entries, create another aci that
allows search/read access to <A
href="ldap:///anyone">ldap:///anyone</A> (and at least make it
targetattr!="userpassword"), and so on..</FONT></SPAN></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff size=2> -
Jeff</FONT></SPAN></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><SPAN
class=373402917-10122007> </SPAN></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
</DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT face=Tahoma
size=2><B>From:</B> fedora-directory-users-bounces@redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] <B>On Behalf Of </B>Chun Tat
David Chu<BR><B>Sent:</B> Monday, December 10, 2007 11:37 AM<BR><B>To:</B>
fedora-directory-users@redhat.com<BR><B>Subject:</B> Re:
[Fedora-directory-users] Question about ACI<BR></FONT><BR></DIV>
<DIV></DIV>Hi guys,<BR><BR>Please see below for my original question.<BR><BR>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. <BR><BR>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). <BR><BR>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.<BR><BR>Any idea? Am I missing some obvious?
<BR><BR>Thanks!<BR><BR>David<BR><BR>
<DIV class=gmail_quote>On Dec 7, 2007 6:28 PM, Chun Tat David Chu <<A
href="mailto:beyonddc.storage@gmail.com">beyonddc.storage@gmail.com</A>>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Hi
guys,<BR><BR>I am trying to create an organizational unit and an user with
ACI, but it looks like my ACI is not defined correctly.<BR>Below is my
ldif.<BR><BR>dn: ou=serviceaccounts,dc=test,dc=example,dc=com<BR>changetype:
add <BR>objectclass: top<BR>objectclass:
organizationalunit<BR>aci:<BR> (targetattr = "*")<BR> (version
3.0;<BR> acl "default aci for service accounts";<BR> allow
(all)<BR> (userdn="ldap:///anyone") <BR> ;)<BR><BR>dn:
cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com<BR>changetype:
add<BR>objectclass: top<BR>objectclass: person<BR>sn:
tscei.obs<BR>userPassword: testing123<BR>description: This is a
test<BR>aci:<BR> (targetattr = "*")<BR> (version 3.0;<BR> acl
"user1";<BR> deny
(all)<BR> (userdn="ldap:///self")<BR> ;)<BR><BR>I create an
organizational unit that allows all users to modify it, then I create user1
that denies everything. <BR>I then use the below LDIF to perform a LDAP add
operation.<BR><BR>dn:
cn=testing123,cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com<BR>changetype:
add<BR>objectclass: top<BR>objectclass: room<BR><BR>I use this ldapmodify
command to perform the add operation <BR>ldapmodify -h hostname -p 1389 -D
"cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com" -w testing123 -f
my_test.ldif -x<BR><BR>The add operation succeeded unexpectedly. The
result that I'm looking for should be not enough privilege to perform add
operation. <BR><BR>Anyone knows what's wrong with my ACI
setup?<BR><BR>Thanks!<BR><FONT
color=#888888><BR>David<BR></FONT></BLOCKQUOTE></DIV><BR></BODY></HTML>