slapi-nis

#47 schema-compat: fix ID view lookups
Merged by abbra. Opened by abbra.
abbra/slapi-nis idviews-fixes  into  master

Download 47.patch

When ID view is detected, it needs to be preserved until the end of search
processing. We iterate over groups and need to know about ID views when
collecting the matched entries.

When ID view is detected, we restart map search from the top level
(cn=compat,$SUFFIX).

For the case of top level (cn=compat,$SUFFIX) match, a subtree which
activated ID view usage was not actually going into individual groups to
match overridden filter against the entries in those groups. This was
due to premature comparison with the group DN as
backend_should_descend() would have always matched it and caused to
short-circuit processing with empty entries.

Finally, since all memory allocations during the search must be present
until the search is processed, do not short-circuit 'return 0' from
within. Use a general cleanup code instead.

Resolves: rhbz#1984010

Signed-off-by: Alexander Bokovoy abokovoy@redhat.com

@tbordaz please review.

Metadata Update from @abbra:
- Request assigned

rebased onto 89abd5e409fc0a1006167edfcd1febac6f231cca

Sample session:

# ipa idview-show myview
  ID View Name: myview
  User object overrides: admin
# ipa idoverrideuser-show myview admin
  Anchor to override: admin
  Login shell: /bin/bash12
# ldapsearch -LLLQ -b cn=compat,dc=example,dc=test uid=admin
dn: uid=admin,cn=users,cn=compat,dc=example,dc=test
objectClass: posixAccount
objectClass: ipaOverrideTarget
objectClass: top
gecos: Administrator
cn: Administrator
uidNumber: 1792600000
gidNumber: 1792600000
loginShell: /bin/bash
homeDirectory: /home/admin
ipaAnchorUUID::  <UUID value>
uid: admin
# ldapsearch -LLLQ -b cn=myview,cn=views,cn=compat,dc=example,dc=test uid=admin
dn: uid=admin,cn=users,cn=myview,cn=views,cn=compat,dc=example,dc=test
objectClass: posixAccount
objectClass: top
gecos: Administrator
cn: Administrator
uidNumber: 1792600000
gidNumber: 1792600000
homeDirectory: /home/admin
uid: admin
loginShell: /bin/bash12

It looks to me that it is the first time 'backend_search_find_set_dn_in_group_cb' is used in slapi-nis code.
The code of 'backend_search_find_set_dn_in_group_cb' looks a bit weird. It returns 'answer'=TRUE if target_dn is "within" container_sdn, according to a scope. That looks fine.
But it also returns 'answer=TRUE' if the target_dn is equal to container. So if we call target: "cn=users,dc=domain" for the container "cn=users,dc=domain" scope ONLEVEL, it will return TRUE. Although target is not a child of container.
I can not say if it is invalid but it looks a weird logic to ignore the scope.

But it also returns 'answer=TRUE' if the target_dn is equal to container. So if we call target: "cn=users,dc=domain" for the container "cn=users,dc=domain" scope ONLEVEL, it will return TRUE. Although target is not a child of container.

This is exactly the part that failed for ID view-overridden searches because we never got inside the container otherwise.

Regarding backend_search_find_set_dn_in_group_cb, this part of the code did not change. What was the problem before is that we never reached this point because we failed to descend down to groups in backend_search_find_set_dn_cb.

Is it useful ?
In backend_search_find_set_dn_in_group_cb, answer is set to TRUE in case group_dn=target_dn. So if answer!=TRUE we should not have group_dn=target_dn.

Opps forget my previous comment. I missed that backend_search_find_set_dn_in_group_cb was already used.

Here is an example trace from my debugging session. Notice that "search not matched cn=compat,..."? Prior to the fix it was not even going inside for ID view-overridden searches.

[18/Aug/2022:18:20:43.750996057 +0200] - DEBUG - schema-compat-plugin - searching from "cn=myview,cn=views,cn=compat,dc=example,dc=test" for "(uid=admin)" with scope 2 (sub)
[18/Aug/2022:18:20:43.751968905 +0200] - DEBUG - schema-compat-plugin - Set dn is found: '0' is detected for target 'cn=myview,cn=views,cn=compat,dc=example,dc=test'
[18/Aug/2022:18:20:43.752904119 +0200] - DEBUG - schema-compat-plugin - Attempt to detect ID view: 'myview' is detected for target 'cn=compat,dc=example,dc=test'
[18/Aug/2022:18:20:43.753760067 +0200] - DEBUG - schema-compat-plugin - Attempt to detect ID view: 'myview' is detected, searching from "cn=compat,dc=example,dc=test" for "(uid=admin)" with scope 2 (sub). Answer is '1'.
[18/Aug/2022:18:20:43.754553838 +0200] - DEBUG - schema-compat-plugin - Use of ID view 'myview' is detected, searching from "cn=compat,dc=example,dc=test" for "(uid=admin)" with scope 2 (sub). Filter may get overridden later.
[18/Aug/2022:18:20:43.755396135 +0200] - DEBUG - schema-compat-plugin - Search metadata from ID view 'cn=myview,cn=views,cn=accounts,dc=example,dc=test'
[18/Aug/2022:18:20:43.756907120 +0200] - DEBUG - schema-compat-plugin - Search metadata from ID view 'cn=myview,cn=views,cn=accounts,dc=example,dc=test' succeeded.
[18/Aug/2022:18:20:43.757854637 +0200] - DEBUG - schema-compat-plugin - Searching for an override of the filter uid with uid=admin from the overrides
.[18/Aug/2022:18:20:43.758675282 +0200] - DEBUG - schema-compat-plugin - ID view filter replacement. Filter now is '(uid=admin)', ID view 'myview', name 'admin'
[18/Aug/2022:18:20:43.759538397 +0200] - DEBUG - schema-compat-plugin - search matched cn=compat,dc=example,dc=test group, let's see about the filter test
[18/Aug/2022:18:20:43.760500311 +0200] - DEBUG - schema-compat-plugin - search not matched cn=compat,dc=example,dc=test
[18/Aug/2022:18:20:43.761631557 +0200] - DEBUG - schema-compat-plugin - descend in group cn=compat,dc=example,dc=test
[18/Aug/2022:18:20:43.769218236 +0200] - DEBUG - schema-compat-plugin - search matched uid=admin,cn=users,cn=compat,dc=example,dc=test
[18/Aug/2022:18:20:43.778488994 +0200] - DEBUG - schema-compat-plugin - search matched uid=admin,cn=users,cn=compat,dc=example,dc=test, is there ID view? 'myview'
[18/Aug/2022:18:20:43.787759388 +0200] - DEBUG - schema-compat-plugin - Process overrides for 'cn=users' in 'cn=compat,dc=example,dc=test'
[18/Aug/2022:18:20:43.796946115 +0200] - DEBUG - schema-compat-plugin - There is an override entry for 'cn=users' in 'cn=compat,dc=example,dc=test'
[18/Aug/2022:18:20:43.807460087 +0200] - DEBUG - schema-compat-plugin - search did not match ou=sudoers,dc=example,dc=test group
[18/Aug/2022:18:20:43.816213976 +0200] - DEBUG - cos-plugin - cos_cache_query_attr - cos attribute krbPwdPolicyReference failed schema check on dn: uid=admin,cn=users,cn=myview,cn=views,cn=compat,dc=example,dc=test
[18/Aug/2022:18:20:43.825701226 +0200] - DEBUG - schema-compat-plugin - sending error 0

It looks a bit radical change. I am surprise to see this change and the change in backend_search_find_set_dn_cb.
Are they both required to fix the issue ?

The change in backend_search_find_set_dn_cb was required. I am not sure about 

-       if (slapi_sdn_scope_test(group_dn, cbdata->target_dn, cbdata->scope)) {
+       if (slapi_sdn_scope_test(cbdata->target_dn, group_dn, cbdata->scope)) {

I did change it because we should consider group_dn a base here, not the target DN we use.

Regarding the change in backend_search_find_set_dn_cb, it looks okay to me. although I wonder if the tests (https://pagure.io/slapi-nis/pull-request/47#comment-175933) is useful. IMHO if answer=FALSE, then slapi_sdn_compare should not match and answer remains to FALSE

Regarding the change backend_search_group_cb, target_dn is the search base. Should we go into the block if the search base is under the group_dn ?

rebased onto a895cc4c6277ba64b58b9afe354c34107677b828

I think you may log the cbdata.target_dn (e.g. slapi_sdn_get_dn(cbdata.target_dn))

Ack for the change in backend_search_find_set_dn_cb

The change in backend_search_cb simply the function and make it much easier to understand. ACK

The patch looks good me. Thanks. ACK

rebased onto 8f756e72a6ad9f4b348b5247cc904bc8ed9dd839

Thanks. I added target to the log for the case we miss the containers.

Pull-Request has been merged by abbra
Metadata
tbordaz
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.