> On 28 Feb 2019, at 01:06, Matus Honek <mhonek@xxxxxxxxxx> wrote:
>
> 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.
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 <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
—
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
