8:14 a.m.
I have a fairly complicated ACL set which I need to optimize the
evaluation of. To do this I need to make decisions based on the
requested access level, which currently isn't possible (as far as I know
that is). E.g, most of my ACLs are concerned with whether the entries
and attributes should be read or writable or not, and I would like to
quickly grant search access when that is all that is requested.
One possibility I have considered is to add a new optional <requested
access> field between the existing <who> and the <access> clauses, but
I'm not very happy with that solution as it could easily be mixed with
the existing <access>.
So far my preferred solution is to add two new ACL controls, which I
currently think of as "sufficient" and "requested".
The "sufficient" control should act like "stop" (i.e grant access) if
the effective <access> is sufficient for the requested access level,
"continue" otherwise.
The "requested" control should act like "continue" if the effective
<access> matches what is requested, "break" otherwise.
I initially thought that "break" should be the non-match action in both
controls, but I think "continue" is the best for "sufficient" as that
allows further decisions to be made in the same ACL without repeating
the <to> part in a following ACL. At the cost of repeating the <who>
part in a new condition in the same ACL if "break" was really needed..
I.e, both choices have their ups and downs, and I can live with both.
I also though that "stop" should be the non-match case for "requested"
to make the controls more symmetric. But that removes the ability to
make further decisions in the succeeding rules, which I find highly
unsatisfactory.
These controls would allow access rules like the following to quickly
grant search access if that is all that is requested, while keep on
processing for other access types:
access to <what> by <who> =s sufficient by * break
An access rule where the <who> clauses are only evaluated when write
access is requested could be written like:
access to <what> by * =w requested by <who> =w
Comments? It should be fairly easy to implement these controls, and
I'll volunteer to do it if they are acceptable.
--
Rein Tollevik
Basefarm AS
9:54 a.m.
Rein Tollevik writes:
The "sufficient" control should act like "stop"
(i.e grant access) if
the effective <access> is sufficient for the requested access level,
"continue" otherwise.
It's <access> which grants access, "stop" just says "don't
look for
more access rules to apply". So this in particular makes me nervous:
The "requested" control should act like
"continue" if the effective
<access> matches what is requested, "break" otherwise.
because this:
access to <what> by * =w requested by <who> =w
actually grants everyone else than <who> access too, but only when they
don't need it. That matters if something (now or in the future)
combines and caches access levels for the duration of an operation, or
checks the access level somehow and applies it "by hand".
An alternative would be to make it part of <what> and/or <who>:
access to requested="=w" <rest of <what>> by <who> =w by *
break
That might still get problems with caching, but less severly so.
I suppose it could be defined as an optimization hint which slapd at
least in theory may ignore, so it's a user error if the access rules are
written so it makes a difference whether or not slapd applies it. But
that wouldn't make it easier to understand the access rules:-(
Other notes:
It might be useful to allow stop/continue/break after requested/sufficient.
Is there a reason why you have different access tests? Effective access
"is sufficient for" vs. "matches" requested access.
--
Hallvard
1:50 a.m.
Hallvard B Furuseth wrote:
Rein Tollevik writes:
> The "sufficient" control should act like "stop" (i.e grant
access) if
> the effective <access> is sufficient for the requested access level,
> "continue" otherwise.
It's <access> which grants access, "stop" just says "don't
look for
more access rules to apply". So this in particular makes me nervous:
Yes, this was not the best wording.. It is not the "stop" by itself
that grants access, but since "stop" would only be done after access had
been tested to be granted the overall effect when the stop was taken
would be to grant access.
> The "requested" control should act like
"continue" if the effective
> <access> matches what is requested, "break" otherwise.
because this:
> access to <what> by * =w requested by <who> =w
actually grants everyone else than <who> access too, but only when they
don't need it. That matters if something (now or in the future)
combines and caches access levels for the duration of an operation, or
checks the access level somehow and applies it "by hand".
The <access> in the "requested" control would have to be tested without
being assigned to the effective access. Which is not how the other
<access> assignments are evaluated :-(
Caching would have to include the requested access level. Given the
dynamic nature of some ACL conditions (dynacl, sets), it is already
questionably how much can be cached.. The current access_allowed() API
returns a boolean grant/deny status for a requested access, so external
"by hand" access level checks would, apart from being bad coding, not
make any sense.
An alternative would be to make it part of <what> and/or
<who>:
access to requested="=w" <rest of <what>> by <who> =w by *
break
That might still get problems with caching, but less severly so.
Yes, this looks as a better approach than the "requested" control. But
doing it belongs in another proposal.
I first thought of the "requested" control as "required", and it was a
direct opposite to "sufficient". But I didn't find it very useful (at
least for me), and it evolved into "requested". Which probably was an
unfortunate diversion, since it differ from the current <access> concept.
I now think it is best to go back to "sufficient" and "required" (or
some better names?). "sufficient" would "stop" if the effective
<access>
grants access, "continue" otherwise, while "required" would
"stop" if
the <access> denies access, "continue" otherwise.
The usage rules would be that "sufficient" can be used when all
succeeding rules grants privileges above the <access> level, while
"required" can be used when the succeeding rules all grants fewer
privileges.
The current effective access level can be tested without altering it
with an access of "+0" (or doing the equivalent of leaving it out).
And, provided the "continue" control would be taken in the no-stop case,
the following would be equivalent (although the first variants should
definitely not be the preferred):
access to * by * <access> sufficient
access to * by * <access>
as would these:
access to * by * <access> required
access to * by * none
These follows from the implicit "by * none" at the end of all ACLs.
I suppose it could be defined as an optimization hint which slapd at
least in theory may ignore, so it's a user error if the access rules are
written so it makes a difference whether or not slapd applies it. But
that wouldn't make it easier to understand the access rules:-(
Other notes:
It might be useful to allow stop/continue/break after requested/sufficient.
Yes, I was thinking along those lines too, although I put them in the
opposite order. I ditched it since it would introduce a new concept
into the ACLs, which I didn't want to do. It would eliminate the
problem of whether "continue" or "break" should be the actions in the
no-stop case though..
Is there a reason why you have different access tests? Effective
access
"is sufficient for" vs. "matches" requested access.
Yes, the unfortunate diversion mentioned above...
Rein
5:14 a.m.
Rein Tollevik wrote:
The current access_allowed() API
returns a boolean grant/deny status for a requested access, so external
"by hand" access level checks would, apart from being bad coding, not
make any sense.
Forget this! I overlooked the maskp argument to access_allowed(), as
well as the access_allowed_mask() function :-(
Rein
1:53 a.m.
Rein Tollevik wrote:
I have a fairly complicated ACL set which I need to optimize the
evaluation of. To do this I need to make decisions based on the
requested access level, which currently isn't possible (as far as I know
that is). E.g, most of my ACLs are concerned with whether the entries
and attributes should be read or writable or not, and I would like to
quickly grant search access when that is all that is requested.
One possibility I have considered is to add a new optional<requested
access> field between the existing<who> and the<access> clauses, but
I'm not very happy with that solution as it could easily be mixed with
the existing<access>.
For what it's worth, HP had a similar requirement. We showed them how to write
a dynacl module to intercept regular ACL processing and do what they needed.
It seems to me that you should be able to at least prototype using dynacl
first, to gain some experience with the real effects of these controls, before
progressing further in the core code.
So far my preferred solution is to add two new ACL controls, which I
currently think of as "sufficient" and "requested".
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5068
days inactive
5071
days old
4 comments
4 participants
participants (4)
-
Hallvard B Furuseth -
Howard Chu -
Rein Tollevik -
Rein Tollevik