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 <wbrown@xxxxxxx> wrote:
>
>
>
> > On 26 Feb 2019, at 12:58, Anuj Borah <aborah@xxxxxxxxxx> 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 <wbrown@xxxxxxx> wrote:
> >
> >
> > > On 26 Feb 2019, at 05:09, Anuj Borah <aborah@xxxxxxxxxx> 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 -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> > > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > > 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/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> >
> > —
> > Sincerely,
> >
> > William Brown
> > Software Engineer, 389 Directory Server
> > SUSE Labs
> > _______________________________________________
> > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > 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/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
>
> —
> Sincerely,
>
> William Brown
> Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Matúš Honěk
Software Engineer
Red Hat Czech
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
