Re: Error 18: Solaris 10 Native LDAP-Client

[Benjamin Griese <der.darude@gmail.com>]

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)
>



-- 
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
be is to do -- Sartre | Do be do be do -- Sinatra