rein@OpenLDAP.org wrote:

rein@OpenLDAP.org skrev:

...

Howard Chu wrote:

...

rein@OpenLDAP.org wrote:

...

The global ACLs are not added to newly created backends, i.e a server restart must be done before they are included. The patch at the end should fix this. OK to commit Howard?

My preference here would be to rip out everything that appends the global ACLs and instead change the access_allowed checker to reference the global ACLs directly when needed.

Agreed, that would also fix the problem that dynamic updates to the global ACLs requires a restart to be effective. I can look into this next week. To be sure I have the semantics correct, it should be to evalutate ALCs local to the backend first, then the global, until a matching entry has been found?

I have finally had time to look at this, and I have uploaded a suggestion for a patch to ftp://ftp.openldap.org/incoming/ITS5572.patch,

The AccessControlState cache and its backtracking was complicating things a bit, but I hope I have got it correct. All the tests succeed with the patch, although I'm not sure whether the cache is actually tested or not..

This looks OK to me, but Ando should probably have a look as well.

I haven't done anything with the code that avoids messing with the global ACL part when modifications are done to a backend ACL, it will simply not find any trailing frontend ACL to stay away from.

I'll remove that code after this is committed.

There is a probably a similar problem in the pcache and translucent overlays, as they makes a copy of the backend ACL when initializing. I.e changes to the backend ACL would not be noticed until a restart? I haven't look any further into this, but a bi_access_allowed function that dynamically fetches the be_acl from the backend could be a fix.

Hm... Have to re-think how this is handled. There are other backend parameters being copied as well.