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.
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.
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
