On Wed, Feb 27, 2019 at 9:10 AM Ludwig Krispenz <lkrispen@xxxxxxxxxx> 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 <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
> >
> >
>
> --
> 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 -- 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
