#3116 ipa: netgroup htable uses different case for keys when storing and retrieving netgroups
Closed: Duplicate None Opened 7 years ago by mzidek.

When processing netgroups in the IPA provider, we use hash table to store all members. We lowercase the key (DN) when storing data to this hash table, but do not do the same when retrieving them.

This caused that member netgroups where never returned.

Steps to reproduce (with ipa provider):[[BR]]

  1. have nested netgroups. For example (NETGROUP_NAME: MEMBER1, MEMBER2, ...):
    • ng1: user1
    • ng2: user2, ng1
  2. getent netgroup ng2
  3. check if ng2 is in chache (ldbedit)

Current results: ng 2 is not cached


Fields changed

owner: somebody => mzidek
patch: 0 => 1

Could you provide a reproducer?
It would be very useful for writing a test.

cc: => lslebodn

I would say this ticket is a duplicate of #3117

It is not duplicate of #3117. I added steps to reproduce and attached patch so that it is not lost in time/devel-list.

description: When processing netgroups in the IPA provider, we use hash table to store all members. We lowercase the key (DN) when storing data to this hash table, but do not do the same when retrieving them.

This caused that member netgroups where never returned. => When processing netgroups in the IPA provider, we use hash table to store all members. We lowercase the key (DN) when storing data to this hash table, but do not do the same when retrieving them.

This caused that member netgroups where never returned.

Steps to reproduce (with ipa provider):[[BR]]

  1. have nested netgroups. For example (NETGROUP_NAME: MEMBER1, MEMBER2, ...):
    * ng1: user1
    * ng2: user2, ng1
  2. getent netgroup ng2
  3. check if ng2 is in chache (ldbedit)

Current results: ng 2 is not cached

All data in sssd cache are internal things. Checking internal things should not be done with integration test.
If there is not a way how to test this without checking sssd cache then provided patch is not sufficient. There is missing an unit test.

If there is a way (even indirect) how to test this bug without checking internal data then please change steps to reproduce.

I never said the steps to reproduce are for integration test. It just shows what the problem is (== netgroup is not stored in cache).

The bug described in #3117 is still present after applying this patch. As I already said on the devel list, I am Ok if the two tickets are pushed together, even though I do not see reason for it, because the bug described here is IMO obvious.

If you want to test it by other means then looking into the cache, then instead of looking inside the cache you can wait for negative cache to expire and run getent netgroup again. With this patch you will see correct results, without it you will see nothing.

Btw. I do not think it makes sense to write integration test for this ticket. Integration test for ticket #3117 would make more sense (if we had infrastructure for it).

Thank you very much for confirmation that steps for reproducing are not for integration test.

We needn't have a separate ticket for each patch.
and the fix is required for proper resolving of nested netgroups. It's better to track it in single ticket; So in case of back-porting to older branches we will not miss it.

Closing as a duplicate of #3117

resolution: => duplicate
status: new => closed

Metadata Update from @mzidek:
- Issue assigned to mzidek
- Issue marked as blocked by: #3117
- Issue set to the milestone: NEEDS_TRIAGE

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4149

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata