[Fedora-directory-devel] ACI evaluation

Richard Megginson rmeggins at redhat.com
Wed Oct 12 12:50:10 UTC 2005


discover wrote:
> I have used the ACL logging and is helpful a little . It does not show 
> the "weight" or "cost" of each acl evaluation . As David mentioned , 
> may be trying it out may be the only way?!
Yes.  If you want to get the raw performance data, the only way is to 
run some tests yourself.
> Also the logs show AC s evaluating entry/attribute rights for the 
> client DN for attributes neither  in the filter nor in the  attributes 
> to return .I was expecting to see only for the attributes in the 
> search filter or the returned attributes .
I think that's just the way it works.
>
> Also the ACL Cache, what is the size ? Does this come out of entrycache ?
No, it has its own separate cache.  You probably won't notice it unless 
you have thousands of ACIs.
>
> Is ACL eval memory intensive ?
Only if you have thousands of ACIs.
> Thanks
>
> Rich Megginson wrote:
>> There are two useful ACI development utilities.  The first is the 
>> special ACL Summary error log level.  This can provide very useful 
>> information about ACI evaluation without the extremely verbose output 
>> of the "regular" aci log level.  The second is the Get Effective 
>> Rights query, so you can do queries like "If I were to BIND as user 
>> X, would I be able to read/write this attribute?  If I were to bind 
>> as user X, what attributes would be visible to me?".
>>
>> Jeff Clowser wrote:
>>
>>> I don't think the order in which they are processed matters (maybe 
>>> very slightly from a performance pov, but not from a "what can I do" 
>>> pov).
>>>
>>> Denies take precedence over allows no matter where they are, and all 
>>> aci's are cumulative, so your access is the combined set of 
>>> permissions defined, no matter the order they are in.  Also, deny is 
>>> the default, so a lack of an aci to allow something will deny it 
>>> (FWIW, I never use deny aci's if at all possible, because there is 
>>> no way to override them with a subsequent allow - better to 
>>> carefully define what you allow and where).
>>>
>>> This is much different than openldap aci's, where the order is very 
>>> important.
>>>
>>> In your example, presumably anonymous will have some base level of 
>>> access, and config, directory, and group admin aci's will give 
>>> additional access.  Adding a user to each of these groups will 
>>> extend their access by what each aci allows, and putting users in 
>>> more than one of these groups will just allow them more access, but 
>>> the order they appear in doesn't matter (and given that they are in 
>>> the same entry, there is no way to specify/guarantee the order anyway).
>>>
>>> - Jeff
>>>
>>> discover wrote:
>>>
>>>> Thanks David . Regarding the order of ACI , I meant for example, 
>>>> say there are 4 ACIs on dc=example,dc=com.
>>>> One for config admins, one for directory admins, Anonymous Access 
>>>> and one for group admin listed in that order. Whether this 
>>>> particular order has any impact ? Or the order is insignificant ?
>>>>
>>>> David Boreham wrote:
>>>>
>>>>> discover wrote:
>>>>>
>>>>>> Is there any way to see the order of ACI evaluation for 
>>>>>> search/mod ...etc ? 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Not easily. You might me able to glean some information by enabling
>>>>> access control logging and looking at the error log output when 
>>>>> you submit
>>>>> an operation.
>>>>>
>>>>>> Also does the order of ACI impact the performance ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Probably not. (not sure if you mean the order the aci attributes
>>>>> are added to the DS -- in that case absolutely not; or if you
>>>>> are asking about the internal ordering of clauses within a
>>>>> single aci -- in that case probably not).
>>>>>
>>>>> To gain a total understanding you'd really need to step through
>>>>> the code in the debugger, which would only suit those
>>>>> with a strong constitution.
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Fedora-directory-devel mailing list
>>>>> Fedora-directory-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Fedora-directory-devel mailing list
>>>> Fedora-directory-devel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>>
>>>
>>>
>>> -- 
>>> Fedora-directory-devel mailing list
>>> Fedora-directory-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>
>> ------------------------------------------------------------------------
>>
>> --
>> Fedora-directory-devel mailing list
>> Fedora-directory-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>   
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-devel mailing list
> Fedora-directory-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3312 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20051012/4bb0e03a/attachment.bin>


More information about the Fedora-directory-devel mailing list