[Fedora-directory-devel] ACI evaluation

[discover]

Is there any way to see the order of ACI evaluation for search/mod 
...etc ? Also does the order of ACI impact the performance ?

Thanks

[David Boreham]

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.

[discover]

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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>

[Jeff Clowser]

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(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-devel
> >
>
>
>  -- 
>  Fedora-directory-devel mailing list
>  Fedora-directory-devel(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-devel

[Rich Megginson]

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(a)redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
> >>
> >
> >
> > -- 
> > Fedora-directory-devel mailing list
> > Fedora-directory-devel(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>
>
>
>  -- 
>  Fedora-directory-devel mailing list
>  Fedora-directory-devel(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-devel

[discover]

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?!

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 .

Also the ACL Cache, what is the size ? Does this come out of entrycache ?

Is ACL eval memory intensive ?
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(a)redhat.com
> >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
> >>>
> >>
> >>
> >> -- 
> >> Fedora-directory-devel mailing list
> >> Fedora-directory-devel(a)redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
> >
> >
> >
> >
> > -- 
> > Fedora-directory-devel mailing list
> > Fedora-directory-devel(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-devel mailing list
> Fedora-directory-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>   
>

[Rich Megginson]

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(a)redhat.com
> >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
> >>>>
> >>>
> >>>
> >>> -- 
> >>> Fedora-directory-devel mailing list
> >>> Fedora-directory-devel(a)redhat.com
> >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
> >>
> >>
> >>
> >> -- 
> >> Fedora-directory-devel mailing list
> >> Fedora-directory-devel(a)redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
> >
> > ------------------------------------------------------------------------
> >
> > --
> > Fedora-directory-devel mailing list
> > Fedora-directory-devel(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-devel
> >   
>
>  ------------------------------------------------------------------------
>
>  --
>  Fedora-directory-devel mailing list
>  Fedora-directory-devel(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>

[David Boreham]

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 ? 
The order isn't supposed to be significant (in fact, there is no defined
order, but in reality I bet the server reads the acis in the order they
were added).

It's possible that the order could affect performance in the case
that an expensive to evaluate aci comes after or before a cheap to evaluate
aci that denies access. Evaluation may stop when access is found
to be denied.

You'd need to run tests to determine if this is the case or not.
I don't think the acl code is smart enough to decide which acis
might be more or less expensive to evaluate (like a database
query planner would do, for example).