On 28 Feb 2019, at 01:06, Matus Honek <mhonek(a)redhat.com>
wrote:
On Wed, Feb 27, 2019 at 9:10 AM Ludwig Krispenz <lkrispen(a)redhat.com> 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(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...
>>
>>
>
> --
> 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(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