[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ACL processing: additive privs (using control continue)

On Aug 5, 2012, at 1:58 PM, Dora Paula <deepee@gmx.net> wrote:

Another (at least to me much better) solution seems to be to get rid of the implicit "by * none" code:
It represents neither a reasonable security functionality, nor a valueable convenience feature - the opposite seems true: Implicit (hidden) "security" hides mission critical settings and functionallity, causes headache that leads to misinterpretation that can result in wrong asumptions (not only for beginners, even for experts, see above).
The (need for) discussion represents just one sign for the inconvenience caused by such a kind of "convenience feature".
With cn=config a missing "by * none" (as any other) acl statement can be added during runtime without the past time (slapd.conf) need to restart slapd. Although the implicit "by * none" seems outdated, specifying adequate frontend acls "implicit (but documented in the configuration) by * none" has been already achievable for some time in the past until today.

I find your argument to be a bit stretched.

First, what you actually suggest is to REPLACE the implicit rule with another implicit rule.   So your argument that implicit rules are bad would equally apply to "by +none stop" as it applies "by =none stop".  And what you asking for is simply a convenience, you don't want to add the "by +none stop" yourself.

While if  we were designing the ACL system today I might have chosen something else, that's not what we're doing.  The only time this change would have been reasonable to make was when additiive/substructive ACLs where added.   And, IIRC, we actually discussed making the change at that time and that we concluded leaving the default by clause as it was for years before was best.

Now some years latter, changing the default would be a really bad idea as that may well change the evaluation of deployed ACLs. 

As far as your more complex suggestion, I think it's overly complex.  What I would want to see before it (or any change to ACLs) be even considered is a clear description of the use case, an clear explanation as to why the current ACL system cannot met the use case without change, and how the change preserves evaluation of existing deployed ACLs.   That's something better discussed on the devel list.

-- Kurt