Fwd: Filter does not work with Anonymous connection

[Anuj Borah]

Hi all,

We have recently implemented Filter and Anonymous to lib389  . But it seems
like Filter does not work with Anonymous connection .
It actually does not work with any kind of connection whether ACI allow or
not  rather than root  .

My suspense is it is related to this issue which is not yet fixed:
https://pagure.io/389-ds-base/issue/50137

Please check attached test case .

Regards
Anuj Borah

[William Brown]

> On 26 Feb 2019, at 05:09, Anuj Borah  wrote:
>
> Hi all,
>
> We have recently implemented Filter and Anonymous to lib389  . But it seems like Filter does not work with Anonymous connection . 
> It actually does not work with any kind of connection whether ACI allow or not  rather than root  .
>
> My suspense is it is related to this issue which is not yet fixed: https://pagure.io/389-ds-base/issue/50137
>
> Please check attached test case .

I suspect they are not related, more likely the access control in your test doesn’t allow anonymous to search objectClass under DEFAULT_SUFFIX. If you change it to:

Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr=“mail || objectClass")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))

(I hope I have the aci syntax correct)
> Regards
> Anuj Borah
> <test.py>_______________________________________________
> 389-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs

[Anuj Borah]

@William Brown

ACI syntax in test is correct,  it meant to give access to (mail = * ) only
not any thing else . In the same case as mansion bellow:

Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci",
'(target="ldap:///{}")(targetattr="mail")(version 3.0; acl "Test";allow
(read,search,compare) (userdn = "ldap:///anyone");
)'.format(DEFAULT_SUFFIX))

conn = Anonymous(topo.standalone).bind()
    # filter does not works with Anonymous
    assert 0 == Accounts(conn, DEFAULT_SUFFIX).filter('(mail=*)')   -----
It does not work
    assert 3 == len(conn.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
"mail=*")) ----- it works

We can clearly see sarch_s works under conn while ACI access to (mail=*) ,
in the same condition filter does not work at all . It gives 0 result ,
while search_s gives 3 .

On Tue, Feb 26, 2019 at 5:06 AM William Brown  wrote:
> > On 26 Feb 2019, at 05:09, Anuj Borah  wrote:
> >
> > Hi all,
> >
> > We have recently implemented Filter and Anonymous to lib389  . But it
>
> seems like Filter does not work with Anonymous connection .
> > It actually does not work with any kind of connection whether ACI allow
>
> or not  rather than root  .
> > My suspense is it is related to this issue which is not yet fixed:
>
> https://pagure.io/389-ds-base/issue/50137
> > Please check attached test case .
>
> I suspect they are not related, more likely the access control in your
> test doesn’t allow anonymous to search objectClass under DEFAULT_SUFFIX. If
> you change it to:
> Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci",
>
> '(target="ldap:///{}")(targetattr=“mail || objectClass")(version 3.0; acl
> "Test";allow (read,search,compare) (userdn = "ldap:///anyone");
> )'.format(DEFAULT_SUFFIX))
>
> (I hope I have the aci syntax correct)
> > Regards
> > Anuj Borah
> > <test.py>_______________________________________________
> > 389-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]....
>
> —
> Sincerely,
>
> William Brown
> Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]....

Filter does not work with Anonymous connection

[William Brown]

> On 26 Feb 2019, at 12:58, Anuj Borah  wrote:
>
> @William Brown
>
> ACI syntax in test is correct,  it meant to give access to (mail = * ) only not any thing else . In the same case as mansion bellow:

Ummm, that’s not what I’m saying? I’m saying that you may *only* be giving access to the mail attribute, so as a result when the .filter generates and expands to (&(objectClass=account)(mail=*)), the objectClass is denied on the searcch, causing the test to fail (to prevent disclosure).

That’s why I suggest changing the aci to allowing mail AND objectClass, and testing again. I think this is atn aci issue not a python, and I’d like to rule out that first.
> Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr="mail")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
> conn = Anonymous(topo.standalone).bind()
> # filter does not works with Anonymous
> assert 0 == Accounts(conn, DEFAULT_SUFFIX).filter('(mail=*)')   -----  It does not work 
> assert 3 == len(conn.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, "mail=*")) ----- it works 
>
>
> We can clearly see sarch_s works under conn while ACI access to (mail=*) , in the same condition filter does not work at all . It gives 0 result , while search_s gives 3 .
>
> On Tue, Feb 26, 2019 at 5:06 AM William Brown  wrote:
> > On 26 Feb 2019, at 05:09, Anuj Borah  wrote:
> >
> > Hi all,
> >
> > We have recently implemented Filter and Anonymous to lib389  . But it seems like Filter does not work with Anonymous connection . 
> > It actually does not work with any kind of connection whether ACI allow or not  rather than root  .
> >
> > My suspense is it is related to this issue which is not yet fixed: https://pagure.io/389-ds-base/issue/50137
> >
> > Please check attached test case .
>
> I suspect they are not related, more likely the access control in your test doesn’t allow anonymous to search objectClass under DEFAULT_SUFFIX. If you change it to:
> Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr=“mail || objectClass")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
>
> (I hope I have the aci syntax correct)
> > Regards
> > Anuj Borah
> > <test.py>_______________________________________________
> > 389-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
>
> —
> Sincerely,
>
> William Brown
> Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs

Filter does not work with Anonymous connection

[Matus Honek]

This kinda leads me to thinking we should implement ACIs management
within the DSLdapObjects like this (probably specific to a particular
subclass, to a degree). One that would take care of this added
requirement for objectclass ACIs because of hidden .filter's behavour.
Because that is currently really hard to be understood at a first
glance, or second.
On Tue, Feb 26, 2019 at 4:02 AM William Brown  wrote:
> > On 26 Feb 2019, at 12:58, Anuj Borah  wrote:
> >
> > @William Brown
> >
> > ACI syntax in test is correct,  it meant to give access to (mail = * ) only not any thing else . In the same case as mansion bellow:
>
> Ummm, that’s not what I’m saying? I’m saying that you may *only* be giving access to the mail attribute, so as a result when the .filter generates and expands to (&(objectClass=account)(mail=*)), the objectClass is denied on the searcch, causing the test to fail (to prevent disclosure).
>
> That’s why I suggest changing the aci to allowing mail AND objectClass, and testing again. I think this is atn aci issue not a python, and I’d like to rule out that first.
> > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr="mail")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
> > conn = Anonymous(topo.standalone).bind()
> > # filter does not works with Anonymous
> > assert 0 == Accounts(conn, DEFAULT_SUFFIX).filter('(mail=*)')   -----  It does not work
> > assert 3 == len(conn.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, "mail=*")) ----- it works
> >
> >
> > We can clearly see sarch_s works under conn while ACI access to (mail=*) , in the same condition filter does not work at all . It gives 0 result , while search_s gives 3 .
> >
> > On Tue, Feb 26, 2019 at 5:06 AM William Brown  wrote:
> > > On 26 Feb 2019, at 05:09, Anuj Borah  wrote:
> > >
> > > Hi all,
> > >
> > > We have recently implemented Filter and Anonymous to lib389  . But it seems like Filter does not work with Anonymous connection .
> > > It actually does not work with any kind of connection whether ACI allow or not  rather than root  .
> > >
> > > My suspense is it is related to this issue which is not yet fixed: https://pagure.io/389-ds-base/issue/50137
> > >
> > > Please check attached test case .
> >
> > I suspect they are not related, more likely the access control in your test doesn’t allow anonymous to search objectClass under DEFAULT_SUFFIX. If you change it to:
> > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr=“mail || objectClass")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
> >
> > (I hope I have the aci syntax correct)
> > > Regards
> > > Anuj Borah
> > > <test.py>_______________________________________________
> > > 389-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> >
> > —
> > Sincerely,
> >
> > William Brown
> > Software Engineer, 389 Directory Server
> > SUSE Labs
> > _______________________________________________
> > 389-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
>
> —
> Sincerely,
>
> William Brown
> Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

Filter does not work with Anonymous connection

[Anuj Borah]

@Matus Honek

Yes, I agree.

Perhaps we should open one ticket in pagur to track this issue ?

Regards
Anuj Borah

On Tue, Feb 26, 2019 at 9:12 PM Matus Honek  wrote:
> This kinda leads me to thinking we should implement ACIs management
> within the DSLdapObjects like this (probably specific to a particular
> subclass, to a degree). One that would take care of this added
> requirement for objectclass ACIs because of hidden .filter's behavour.
> Because that is currently really hard to be understood at a first
> glance, or second.
> On Tue, Feb 26, 2019 at 4:02 AM William Brown  wrote:
> > > On 26 Feb 2019, at 12:58, Anuj Borah  wrote:
> > >
> > > @William Brown
> > >
> > > ACI syntax in test is correct,  it meant to give access to (mail = * )
>
> only not any thing else . In the same case as mansion bellow:
> > Ummm, that’s not what I’m saying? I’m saying that you may *only* be
>
> giving access to the mail attribute, so as a result when the .filter
> generates and expands to (&(objectClass=account)(mail=*)), the objectClass
> is denied on the searcch, causing the test to fail (to prevent disclosure).
> > That’s why I suggest changing the aci to allowing mail AND objectClass,
>
> and testing again. I think this is atn aci issue not a python, and I’d like
> to rule out that first.
> > > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci",
>
> '(target="ldap:///{}")(targetattr="mail")(version 3.0; acl "Test";allow
> (read,search,compare) (userdn = "ldap:///anyone");
> )'.format(DEFAULT_SUFFIX))
> > > conn = Anonymous(topo.standalone).bind()
> > > # filter does not works with Anonymous
> > > assert 0 == Accounts(conn, DEFAULT_SUFFIX).filter('(mail=*)')
>
> -----  It does not work
> > > assert 3 == len(conn.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
>
> "mail=*")) ----- it works
> > > We can clearly see sarch_s works under conn while ACI access to
>
> (mail=*) , in the same condition filter does not work at all . It gives 0
> result , while search_s gives 3 .
> > > On Tue, Feb 26, 2019 at 5:06 AM William Brown  wrote:
> > > > On 26 Feb 2019, at 05:09, Anuj Borah  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > We have recently implemented Filter and Anonymous to lib389  . But
>
> it seems like Filter does not work with Anonymous connection .
> > > > It actually does not work with any kind of connection whether ACI
>
> allow or not  rather than root  .
> > > > My suspense is it is related to this issue which is not yet fixed:
>
> https://pagure.io/389-ds-base/issue/50137
> > > > Please check attached test case .
> > >
> > > I suspect they are not related, more likely the access control in your
>
> test doesn’t allow anonymous to search objectClass under DEFAULT_SUFFIX. If
> you change it to:
> > > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci",
>
> '(target="ldap:///{}")(targetattr=“mail || objectClass")(version 3.0; acl
> "Test";allow (read,search,compare) (userdn = "ldap:///anyone");
> )'.format(DEFAULT_SUFFIX))
> > > (I hope I have the aci syntax correct)
> > > > Regards
> > > > Anuj Borah
> > > > <test.py>_______________________________________________
> > > > 389-devel mailing list -- [e-mail]
> > > > To unsubscribe send an email to
>
> [e-mail]
> > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > > List Guidelines:
>
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]....
> > > —
> > > Sincerely,
> > >
> > > William Brown
> > > Software Engineer, 389 Directory Server
> > > SUSE Labs
> > > _______________________________________________
> > > 389-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to
>
> [e-mail]
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines:
>
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]....
> > —
> > Sincerely,
> >
> > William Brown
> > Software Engineer, 389 Directory Server
> > SUSE Labs
> > _______________________________________________
> > 389-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]....
>
> --
> Matúš Honěk
> Software Engineer
> Red Hat Czech

Filter does not work with Anonymous connection

[William Brown]

There is already features in lib389 for managing aci, but due to the design of aci in DS they are *super hard* to represent correctly in DSLdapObjects. I think the existing lib389 aci code could be adapted to extend dsldapobject to have some aci tranform capabilities, but they wouldn’t be “nice” in the same way as other parts of the API are.
> On 27 Feb 2019, at 01:54, Anuj Borah  wrote:
>
> @Matus Honek
>
> Yes, I agree.
>
> Perhaps we should open one ticket in pagur to track this issue ?
>
> Regards
> Anuj Borah
>
> On Tue, Feb 26, 2019 at 9:12 PM Matus Honek  wrote:
> This kinda leads me to thinking we should implement ACIs management
> within the DSLdapObjects like this (probably specific to a particular
> subclass, to a degree). One that would take care of this added
> requirement for objectclass ACIs because of hidden .filter's behavour.
> Because that is currently really hard to be understood at a first
> glance, or second.
> On Tue, Feb 26, 2019 at 4:02 AM William Brown  wrote:
> > > On 26 Feb 2019, at 12:58, Anuj Borah  wrote:
> > >
> > > @William Brown
> > >
> > > ACI syntax in test is correct,  it meant to give access to (mail = * ) only not any thing else . In the same case as mansion bellow:
> >
> > Ummm, that’s not what I’m saying? I’m saying that you may *only* be giving access to the mail attribute, so as a result when the .filter generates and expands to (&(objectClass=account)(mail=*)), the objectClass is denied on the searcch, causing the test to fail (to prevent disclosure).
> >
> > That’s why I suggest changing the aci to allowing mail AND objectClass, and testing again. I think this is atn aci issue not a python, and I’d like to rule out that first.
> > > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr="mail")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
> > > conn = Anonymous(topo.standalone).bind()
> > > # filter does not works with Anonymous
> > > assert 0 == Accounts(conn, DEFAULT_SUFFIX).filter('(mail=*)')   -----  It does not work
> > > assert 3 == len(conn.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, "mail=*")) ----- it works
> > >
> > >
> > > We can clearly see sarch_s works under conn while ACI access to (mail=*) , in the same condition filter does not work at all . It gives 0 result , while search_s gives 3 .
> > >
> > > On Tue, Feb 26, 2019 at 5:06 AM William Brown  wrote:
> > > > On 26 Feb 2019, at 05:09, Anuj Borah  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > We have recently implemented Filter and Anonymous to lib389  . But it seems like Filter does not work with Anonymous connection .
> > > > It actually does not work with any kind of connection whether ACI allow or not  rather than root  .
> > > >
> > > > My suspense is it is related to this issue which is not yet fixed: https://pagure.io/389-ds-base/issue/50137
> > > >
> > > > Please check attached test case .
> > >
> > > I suspect they are not related, more likely the access control in your test doesn’t allow anonymous to search objectClass under DEFAULT_SUFFIX. If you change it to:
> > > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr=“mail || objectClass")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
> > >
> > > (I hope I have the aci syntax correct)
> > > > Regards
> > > > Anuj Borah
> > > > <test.py>_______________________________________________
> > > > 389-devel mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> > >
> > > —
> > > Sincerely,
> > >
> > > William Brown
> > > Software Engineer, 389 Directory Server
> > > SUSE Labs
> > > _______________________________________________
> > > 389-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> >
> > —
> > Sincerely,
> >
> > William Brown
> > Software Engineer, 389 Directory Server
> > SUSE Labs
> > _______________________________________________
> > 389-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
>
> -- 
> Matúš Honěk
> Software Engineer
> Red Hat Czech
> _______________________________________________
> 389-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs

Filter does not work with Anonymous connection

[Ludwig Krispenz]

On 02/26/2019 04:42 PM, Matus Honek wrote:
> This kinda leads me to thinking we should implement ACIs management
> within the DSLdapObjects like this (probably specific to a particular
> subclass, to a degree). One that would take care of this added
> requirement for objectclass ACIs because of hidden .filter's behavour.
> Because that is currently really hard to be understood at a first
> glance, or second.

I think the problem starts with the hiding, if methods do hidden things 
like transforming a filter, it is difficult for an application to know 
what is going on. But if you start adding magic to handle eg the aci 
problem you only increase and will get new unexpected behaviour. I would 
strongly object on silently adding/changing acis.

In my opinion we are at a crossroad with lib389, it has to fulfill two 
purposes

1] provide methods to access and manage a server, the methods should be 
easy to use and as safe as possible

2] provide methods to write test cases, also for scenarios where the 
client does "bad" things, you want to have full control an what is sent 
to the server at a very detailed level. Silently doing additional 
searches or transforming filters is a nogo in that kind of application.

I have the feeling we are more and more drifting to support 1] and 
making it harder to achieve 2]. The announcement that <ldapop>_s will be 
deprecated without offering a replacement for rwa access to the server 
fits in. BTW when was this deprecation discussed and decided ? This is 
nothing just to do on the side way.

Ludwig
> On Tue, Feb 26, 2019 at 4:02 AM William Brown  wrote:
> > > On 26 Feb 2019, at 12:58, Anuj Borah  wrote:
> > >
> > > @William Brown
> > >
> > > ACI syntax in test is correct,  it meant to give access to (mail = * ) only not any thing else . In the same case as mansion bellow:
> >
> > Ummm, that’s not what I’m saying? I’m saying that you may *only* be giving access to the mail attribute, so as a result when the .filter generates and expands to (&(objectClass=account)(mail=*)), the objectClass is denied on the searcch, causing the test to fail (to prevent disclosure).
> >
> > That’s why I suggest changing the aci to allowing mail AND objectClass, and testing again. I think this is atn aci issue not a python, and I’d like to rule out that first.
> > > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr="mail")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
> > >  conn = Anonymous(topo.standalone).bind()
> > >  # filter does not works with Anonymous
> > >  assert 0 == Accounts(conn, DEFAULT_SUFFIX).filter('(mail=*)')   -----  It does not work
> > >  assert 3 == len(conn.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, "mail=*")) ----- it works
> > >
> > >
> > > We can clearly see sarch_s works under conn while ACI access to (mail=*) , in the same condition filter does not work at all . It gives 0 result , while search_s gives 3 .
> > >
> > > On Tue, Feb 26, 2019 at 5:06 AM William Brown  wrote:
> > > > On 26 Feb 2019, at 05:09, Anuj Borah  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > We have recently implemented Filter and Anonymous to lib389  . But it seems like Filter does not work with Anonymous connection .
> > > > It actually does not work with any kind of connection whether ACI allow or not  rather than root  .
> > > >
> > > > My suspense is it is related to this issue which is not yet fixed: https://pagure.io/389-ds-base/issue/50137
> > > >
> > > > Please check attached test case .
> > >
> > > I suspect they are not related, more likely the access control in your test doesn’t allow anonymous to search objectClass under DEFAULT_SUFFIX. If you change it to:
> > >  Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr=“mail || objectClass")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
> > >
> > > (I hope I have the aci syntax correct)
> > > > Regards
> > > > Anuj Borah
> > > > <test.py>_______________________________________________
> > > > 389-devel mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> > >
> > > —
> > > Sincerely,
> > >
> > > William Brown
> > > Software Engineer, 389 Directory Server
> > > SUSE Labs
> > > _______________________________________________
> > > 389-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> >
> > —
> > Sincerely,
> >
> > William Brown
> > Software Engineer, 389 Directory Server
> > SUSE Labs
> > _______________________________________________
> > 389-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

Filter does not work with Anonymous connection

[Matus Honek]

On Wed, Feb 27, 2019 at 9:10 AM Ludwig Krispenz  wrote:
> On 02/26/2019 04:42 PM, Matus Honek wrote:
> > This kinda leads me to thinking we should implement ACIs management
> > within the DSLdapObjects like this (probably specific to a particular
> > subclass, to a degree). One that would take care of this added
> > requirement for objectclass ACIs because of hidden .filter's behavour.
> > Because that is currently really hard to be understood at a first
> > glance, or second.
>
> I think the problem starts with the hiding, if methods do hidden things
> like transforming a filter, it is difficult for an application to know
> what is going on. But if you start adding magic to handle eg the aci
> problem you only increase and will get new unexpected behaviour. I would
> strongly object on silently adding/changing acis.

I did not say it out loud but yes, I fully agree the culprit is that
we're hiding something we were not able to fully cover by our
functionality. So I tried to offer a solution. In the state when we
already do some magic nowadays, either we fix the magic by more magic
or don't do magic at all - for me both work, base on case to case
basis. We're LDAP, we should be allowed to do direct LDAP operations
as we may need to test some special cases.
> In my opinion we are at a crossroad with lib389, it has to fulfill two
> purposes
>
> 1] provide methods to access and manage a server, the methods should be
> easy to use and as safe as possible
>
> 2] provide methods to write test cases, also for scenarios where the
> client does "bad" things, you want to have full control an what is sent
> to the server at a very detailed level. Silently doing additional
> searches or transforming filters is a nogo in that kind of application.
>
> I have the feeling we are more and more drifting to support 1] and
> making it harder to achieve 2]. The announcement that <ldapop>_s will be
> deprecated without offering a replacement for rwa access to the server
> fits in. BTW when was this deprecation discussed and decided ? This is
> nothing just to do on the side way.

I agree. We should be able to use both worlds. For a feature testing
it is ok to have higher level API. But for testing particular corner
cases we must be able to set up the thing precisely. However, we
should try to separate the usage of both worlds as much as possible,
and when using lower level API rely only on higher level API that is
very stable in a sense that we exactly know what operations it will do
so that we're not later on surprised why this or that test suddenly
started to fail because we changed inner behaviour of higher level
API.
> Ludwig
> > On Tue, Feb 26, 2019 at 4:02 AM William Brown  wrote:
> > > > On 26 Feb 2019, at 12:58, Anuj Borah  wrote:
> > > >
> > > > @William Brown
> > > >
> > > > ACI syntax in test is correct,  it meant to give access to (mail = * ) only not any thing else . In the same case as mansion bellow:
> > >
> > > Ummm, that’s not what I’m saying? I’m saying that you may *only* be giving access to the mail attribute, so as a result when the .filter generates and expands to (&(objectClass=account)(mail=*)), the objectClass is denied on the searcch, causing the test to fail (to prevent disclosure).
> > >
> > > That’s why I suggest changing the aci to allowing mail AND objectClass, and testing again. I think this is atn aci issue not a python, and I’d like to rule out that first.
> > > > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr="mail")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
> > > >  conn = Anonymous(topo.standalone).bind()
> > > >  # filter does not works with Anonymous
> > > >  assert 0 == Accounts(conn, DEFAULT_SUFFIX).filter('(mail=*)')   -----  It does not work
> > > >  assert 3 == len(conn.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, "mail=*")) ----- it works
> > > >
> > > >
> > > > We can clearly see sarch_s works under conn while ACI access to (mail=*) , in the same condition filter does not work at all . It gives 0 result , while search_s gives 3 .
> > > >
> > > > On Tue, Feb 26, 2019 at 5:06 AM William Brown  wrote:
> > > > > On 26 Feb 2019, at 05:09, Anuj Borah  wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > We have recently implemented Filter and Anonymous to lib389  . But it seems like Filter does not work with Anonymous connection .
> > > > > It actually does not work with any kind of connection whether ACI allow or not  rather than root  .
> > > > >
> > > > > My suspense is it is related to this issue which is not yet fixed: https://pagure.io/389-ds-base/issue/50137
> > > > >
> > > > > Please check attached test case .
> > > >
> > > > I suspect they are not related, more likely the access control in your test doesn’t allow anonymous to search objectClass under DEFAULT_SUFFIX. If you change it to:
> > > >  Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr=“mail || objectClass")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
> > > >
> > > > (I hope I have the aci syntax correct)
> > > > > Regards
> > > > > Anuj Borah
> > > > > <test.py>_______________________________________________
> > > > > 389-devel mailing list -- [e-mail]
> > > > > To unsubscribe send an email to [e-mail]
> > > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> > > >
> > > > —
> > > > Sincerely,
> > > >
> > > > William Brown
> > > > Software Engineer, 389 Directory Server
> > > > SUSE Labs
> > > > _______________________________________________
> > > > 389-devel mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> > >
> > > —
> > > Sincerely,
> > >
> > > William Brown
> > > Software Engineer, 389 Directory Server
> > > SUSE Labs
> > > _______________________________________________
> > > 389-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
>
> --
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander
> _______________________________________________
> 389-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

Filter does not work with Anonymous connection

[William Brown]

> On 28 Feb 2019, at 01:06, Matus Honek  wrote:
>
> On Wed, Feb 27, 2019 at 9:10 AM Ludwig Krispenz  wrote:
> > On 02/26/2019 04:42 PM, Matus Honek wrote:
> > > This kinda leads me to thinking we should implement ACIs management
> > > within the DSLdapObjects like this (probably specific to a particular
> > > subclass, to a degree). One that would take care of this added
> > > requirement for objectclass ACIs because of hidden .filter's behavour.
> > > Because that is currently really hard to be understood at a first
> > > glance, or second.
> >
> > I think the problem starts with the hiding, if methods do hidden things
> > like transforming a filter, it is difficult for an application to know
> > what is going on. But if you start adding magic to handle eg the aci
> > problem you only increase and will get new unexpected behaviour. I would
> > strongly object on silently adding/changing acis.
>
> I did not say it out loud but yes, I fully agree the culprit is that
> we're hiding something we were not able to fully cover by our
> functionality. So I tried to offer a solution. In the state when we
> already do some magic nowadays, either we fix the magic by more magic
> or don't do magic at all - for me both work, base on case to case
> basis. We're LDAP, we should be allowed to do direct LDAP operations
> as we may need to test some special cases.

I agree, I don’t want magic for this situation, but at some point we’ll need a way to manipulate these via the cli nicely.
> > In my opinion we are at a crossroad with lib389, it has to fulfill two
> > purposes
> >
> > 1] provide methods to access and manage a server, the methods should be
> > easy to use and as safe as possible
> >
> > 2] provide methods to write test cases, also for scenarios where the
> > client does "bad" things, you want to have full control an what is sent
> > to the server at a very detailed level. Silently doing additional
> > searches or transforming filters is a nogo in that kind of application.
> >
> > I have the feeling we are more and more drifting to support 1] and
> > making it harder to achieve 2]. The announcement that <ldapop>_s will be
> > deprecated without offering a replacement for rwa access to the server
> > fits in. BTW when was this deprecation discussed and decided ? This is
> > nothing just to do on the side way.
>
> I agree. We should be able to use both worlds. For a feature testing
> it is ok to have higher level API. But for testing particular corner
> cases we must be able to set up the thing precisely. However, we
> should try to separate the usage of both worlds as much as possible,
> and when using lower level API rely only on higher level API that is
> very stable in a sense that we exactly know what operations it will do
> so that we're not later on surprised why this or that test suddenly
> started to fail because we changed inner behaviour of higher level
> API.

I want to achieve 1 and 2, but honestly, I prefer 1 if it comes to it.

My issue is not with the _s apis, they are a fact of life. It’s the subclass of DirSrv to simpleLdapObject, the fact it has function interception, and the “entry.py” file, and what that brings. Additionally, there are loads of legacy “helpers” in lib389 that use the _s apis, that probably could be using the better dsldapobjects api instead. Finally, there were people who were mis-using the _s api in tests recently, and I wanted a way to say “no, you are doing something wrong”. lib389’s history and legacy has gone through a number of people, who were Java and C programmers, but not python. It really shows in our code, and there is a mountain of tech debt that I am (long term) trying to unbury so we have a really clean, quality code base that people really can use as an API in their projects. (IPA or admins for example).

There is still a way to use the _s apis today (escapehatch), but there is just lots of complexity to get it right around python and bytes handling. It makes for really messy and hard to understand code. So I prefer to not use it if possible - and if we have to use it in a specific way, let’s write a safe, clean wrapper to make it safe to use (and functional for tests).

With regard to where this was discussed? I was talking about this probably about 1.5 yrs at RH, but there obviously was a gap where I was absent, so returning and following through may have been a surprise.

I think as a team, there needs to be a invested effort to be “less Red Hat centric”. I certainly suspect there are conversations and meetings happening without me at Red Hat. Sometimes, that’s fine, like customer cases. But as a project, we have no governance structure, no decision making process, no meetings, and little communication. As someone who is now “on the outside”, it’s really hard to get things moving in this case.

So I think perhaps we need to think about having some improvements to how we operate as an upstream, without Red Hat specific channels.
> > Ludwig
> > > On Tue, Feb 26, 2019 at 4:02 AM William Brown  wrote:
> > > > > On 26 Feb 2019, at 12:58, Anuj Borah  wrote:
> > > > >
> > > > > @William Brown
> > > > >
> > > > > ACI syntax in test is correct,  it meant to give access to (mail = * ) only not any thing else . In the same case as mansion bellow:
> > > >
> > > > Ummm, that’s not what I’m saying? I’m saying that you may *only* be giving access to the mail attribute, so as a result when the .filter generates and expands to (&(objectClass=account)(mail=*)), the objectClass is denied on the searcch, causing the test to fail (to prevent disclosure).
> > > >
> > > > That’s why I suggest changing the aci to allowing mail AND objectClass, and testing again. I think this is atn aci issue not a python, and I’d like to rule out that first.
> > > > > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr="mail")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
> > > > > conn = Anonymous(topo.standalone).bind()
> > > > > # filter does not works with Anonymous
> > > > > assert 0 == Accounts(conn, DEFAULT_SUFFIX).filter('(mail=*)')   -----  It does not work
> > > > > assert 3 == len(conn.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, "mail=*")) ----- it works
> > > > >
> > > > >
> > > > > We can clearly see sarch_s works under conn while ACI access to (mail=*) , in the same condition filter does not work at all . It gives 0 result , while search_s gives 3 .
> > > > >
> > > > > On Tue, Feb 26, 2019 at 5:06 AM William Brown  wrote:
> > > > > > On 26 Feb 2019, at 05:09, Anuj Borah  wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > We have recently implemented Filter and Anonymous to lib389  . But it seems like Filter does not work with Anonymous connection .
> > > > > > It actually does not work with any kind of connection whether ACI allow or not  rather than root  .
> > > > > >
> > > > > > My suspense is it is related to this issue which is not yet fixed: https://pagure.io/389-ds-base/issue/50137
> > > > > >
> > > > > > Please check attached test case .
> > > > >
> > > > > I suspect they are not related, more likely the access control in your test doesn’t allow anonymous to search objectClass under DEFAULT_SUFFIX. If you change it to:
> > > > > Domain(topo.standalone, DEFAULT_SUFFIX).replace("aci", '(target="ldap:///{}")(targetattr=“mail || objectClass")(version 3.0; acl "Test";allow (read,search,compare) (userdn = "ldap:///anyone"); )'.format(DEFAULT_SUFFIX))
> > > > >
> > > > > (I hope I have the aci syntax correct)
> > > > > > Regards
> > > > > > Anuj Borah
> > > > > > <test.py>_______________________________________________
> > > > > > 389-devel mailing list -- [e-mail]
> > > > > > To unsubscribe send an email to [e-mail]
> > > > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> > > > >
> > > > > —
> > > > > Sincerely,
> > > > >
> > > > > William Brown
> > > > > Software Engineer, 389 Directory Server
> > > > > SUSE Labs
> > > > > _______________________________________________
> > > > > 389-devel mailing list -- [e-mail]
> > > > > To unsubscribe send an email to [e-mail]
> > > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> > > >
> > > > —
> > > > Sincerely,
> > > >
> > > > William Brown
> > > > Software Engineer, 389 Directory Server
> > > > SUSE Labs
> > > > _______________________________________________
> > > > 389-devel mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> >
> > --
> > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> > Commercial register: Amtsgericht Muenchen, HRB 153243,
> > Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander
> > _______________________________________________
> > 389-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
>
> -- 
> Matúš Honěk
> Software Engineer
> Red Hat Czech
> _______________________________________________
> 389-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs