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(a)redhat.com>
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(a)redhat.com> 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(a)suse.de> wrote:
>
>
>
> > On 26 Feb 2019, at 12:58, Anuj Borah <aborah(a)redhat.com> 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(a)suse.de> wrote:
> >
> >
> > > On 26 Feb 2019, at 05:09, Anuj Borah <aborah(a)redhat.com> 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(a)lists.fedoraproject.org
> > > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> > > 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@lists.fedoraproje...
> >
> > —
> > Sincerely,
> >
> > William Brown
> > Software Engineer, 389 Directory Server
> > SUSE Labs
> > _______________________________________________
> > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> > 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@lists.fedoraproje...
>
> —
> Sincerely,
>
> William Brown
> Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproje...
--
Matúš Honěk
Software Engineer
Red Hat Czech
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproje...
—
Sincerely,
William Brown
Software Engineer, 389 Directory Server
SUSE Labs