[Fedora-directory-users] ACI

[Richard Megginson]

Craig White wrote:

>On Sun, 2005-12-04 at 17:44 -0500, Jeff Clowser wrote:
>  
>
>>Craig White wrote:
>>
>>    
>>
>>>I have personal address books...each user would have one - i.e.
>>>
>>>ou=AddressBook,uid=craig,ou=People,dc=azapple,dc=com
>>>ou=AddressBook,uid=jennifer,ou=People,dc=azapple,dc=com
>>>
>>>and my thinking is that each person can read/write/delete/etc. their own
>>>address book, authenticated users can read and anonymous is denied.
>>> 
>>>
>>>      
>>>
>>First, a comment on this:  Does user craig really want user jennifer to 
>>see his "personal" addressbooks?  Typically, "personal" addressbooks are 
>>only visible by the person that owns them.  I know I'm questioning your 
>>requirements rather than telling you how to implement what you want, but 
>>thought I'd ask :)
>>    
>>
>----
>finally got through my initial setup to work on these issues and can
>reply back.
>
>Most of my setups are for my clients and they do have workgroups where
>they would possibly need to share address books. So I generally have
>company wide address books and personal address books and permit at
>least some sharing of the personal address books. In addition, since the
>typical address book clients that people would use (Outlook/Thunderbird)
>are incapable of creating/editing entries, it requires some other
>application that some of the people are less than eager to use which
>means that the maintenance of them falls to their underlings
>----
>  
>
>>>Thus I created 3 rules and they aren't working because an
>>>unauthenticated/anonymous bind still can view them...
>>> 
>>>
>>>      
>>>
>>My guess is that at the top of your tree, you have an aci that allows 
>>anonymous to see stuff (probably something like anonymous can 
>>read/search all but userpassword, etc).  Aci's at the top are inherited 
>>"down the tree", so they are visible because of that, not because of 
>>your new aci's.  It's usually hard to create a deny aci for a lower 
>>branch of the tree that works without breaking something else, and I 
>>always try to avoid deny aci's (because they always take precedence and 
>>can never be overridden by any allow aci's, causing some potentially 
>>unexpected results).
>>    
>>
>----
>Yeah you are correct on all these accounts. Obviously the default rule
>is always to not allow whatever isn't expressly permitted and yes, there
>was the default anonymous allow rule that played into it.
>
>What I did discover was if I attached the following ACI to
>ou=AddressBook,dc=clsurvey,dc=com it doesn't work but if I attach it to
>dc=clsurvey,dc=com it does work.
>  
>
I'm not sure why, but most of the time, the (target = ..) clause is not 
necessary.  acis have subtree scope - they apply to the entry containing 
the aci and all children and decendents of that entry.  So if the 
following aci is in the entry dc=clsurvey,dc=com, you don't need the 
(target....) clause.

>(targetattr = "*") 
>(target = "ldap:///*,ou=AddressBook,dc=clsurvey,dc=com") 
>(version 3.0;
>acl "AddressBook Administrator";
>allow (all)
>(userdn =
>"ldap:///uid=Administrator,ou=People,ou=Accounts,dc=clsurvey,dc=com")
>;)
>
>
>Thanks
>
>Craig
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users at redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20051211/d000ccec/attachment.bin>