Hallvard B Furuseth wrote:
Rein Tollevik writes:
> The "sufficient" control should act like "stop" (i.e grant
> the effective <access> is sufficient for the requested access level,
> "continue" otherwise.
It's <access> which grants access, "stop" just says "don't
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.
> 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
access to requested="=w" <rest of <what>> by <who> =w by *
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
grants access, "continue" otherwise, while "required" would
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
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:-(
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
"is sufficient for" vs. "matches" requested access.
Yes, the unfortunate diversion mentioned above...