[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