Hello Ralf,
yes you're right that's the right SR, and yes it's about dynamic loading of modules. I pointed Austin right to you and this thread, just for better communication.
In the meantime I set the ACL, but unfortunatly it didn't help solving the problem, you may take a look at my example:
DN: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=ldapadm,dc=example,dc=de" write by dn="cn=proxyuser,ou=system,ou=people,dc=example,dc=de" read by anonymous auth by self write by * none olcAccess: {1} to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none olcAccess: {2} to dn.base="" attrs=supportedControl val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none olcAccess: {3}to dn.base="" by * read olcAccess: {4}to * by dn="cn=ldapadm,dc=example,dc=de" write by * read
If I remember right {4} is not opening up the access when it is explicitly denied in the ACLs {1} & {2}, am I right? But I'm not sure if this is the right place for this kind of ACL, cn=config instead should be wrong too I guess.
Bye, Benjamin.
On Tue, Nov 2, 2010 at 18:03, Ralf Haferkamp rhafer@suse.de wrote:
Am Dienstag 02 November 2010, 16:57:38 schrieb Benjamin Griese:
Hello Ralf,
nice to know that someone from Novell is reading here, too.
Currently I have opened up a Service Request regarding this topic at Novells Suport Center and pointed that out as a Feature Request but also as problem I and other people have and are lookinf for a workaround.
The feature request is regarding build the overlays as dynamic modules, I guess? Yes that's something we are looking into as well. But for this special SSS/VLV issue there is already a fix in CVS which I we will most probably include in our packages. Changing from static overlays to dynamic overlays is unlikely to happen during the SLES11 timeframe I think (but we are getting off topic ...)
Too bad I am really low experienced in building complex ACLs to filter stuff like this, maybe someone else is able to help us (James and me) to workaround that problem.
Something like this should work:
access to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none access to dn.base="" attrs=supportedControl val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none
I just found out however that there seems to be a bug in the ACL code when the above ACL appear as the first ACL in the configuration :(. I am still trying to track down that problem. So please make sure to have another ACL before them (one that doesn't apply to the "supportedControl" Attribute of course).
I'll give it a shot and let you know if it's working or not. :)
Good luck.
Ralf
-- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)