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 <aborah@xxxxxxxxxx> 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 <mhonek@xxxxxxxxxx> 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 <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
—
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
