[Fedora-directory-users] Question about ACI

Chun Tat David Chu beyonddc.storage at gmail.com
Mon Dec 10 18:31:12 UTC 2007


Thanks Jeff!

I think you cleared everything for me.  I did misunderstood the concept of
"ldap:///self", and I agree with you that deny rules should be avoided.

ldap:///self refers to the owner of the entry which is the creator of the
entry.  Am I correct on this?

After I specified the userdn as
cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com in my ACI, everything
is now working as expected.  user1 doesn't have the ability to
write/add/replace the entry.

Below is my new LDIF
dn: ou=serviceaccounts,dc=test,dc=example,dc=com
 changetype: add
 objectclass: top
 objectclass: organizationalunit

dn: cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com
 changetype: add
 objectclass: top
 objectclass: person
 sn: user1
 userPassword: testing123
 description: This is a test
 aci:
  (targetattr = "*")
  (version 3.0;
  acl "user1";
  allow (read, search, compare)
  (userdn="ldap:///cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com
  ");)

Thanks,

David

On Dec 10, 2007 12:48 PM, Clowser, Jeff (Contractor) <
jeff_clowser at fanniemae.com> wrote:

>  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
> >
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20071210/05124168/attachment.html>


More information about the 389-users mailing list