Optionally allow expanding of groups outside of the group search base

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/961

• Created at 2011-08-12 15:36:00 by prefect
• Closed at 2020-03-24 14:22:18 as wontfix
• Assigned to nobody

---

It should be possible to choose whether or not to expand child groups (a group that's a member of a group where the parent group is within the search base) where the child group is outside of the group search base.

I'm not entirely sure whether this should be a boolean to allow it (but how far, as far as the overall search_base or simply "unlimited"), or if it needs a separate nested_group_search_base to provide a second limit...

Comments

---

Comment from dpal at 2011-08-18 14:57:02

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.7.0

---

Comment from sgallagh at 2011-08-18 17:02:01

Moving this back to NEEDS_TRIAGE. This ticket will need a lot of discussion. It's a very complicated problem and I strongly advise against trying to do this in 1.7.0. Ticket #960 belongs in 1.7.0 so we at least get expected results.

milestone: SSSD 1.7.0 => NEEDS_TRIAGE

---

Comment from dpal at 2011-08-18 17:28:30

As it was explained to me the current functionality is to lookup users outside of the base so the ticket is just to make it configurable to execute current code path or the one that will be implemented in #960. I do not see how it is complex but may be I am missing something or you see the scope of the ticket differently.

---

Comment from sgallagh at 2011-08-18 19:13:20

The current code does not look up users outside of the base in a sane way. The short version is that a group can list some users that you can't individually look up.

The longer version is that when a group is looked up, if it has member DNs that are not currently cached, we will create a temporary fake user in the cache. The idea is that later on when that user is directly requested, the cache entry will be updated with the complete set of user data. However, because this user is outside the search base, this entry will NEVER be updated (and is essentially wasted space in the database).

So in order to solve this ticket properly, we need to ensure that we only store users in the sysdb that can be looked up in LDAP. There are a few potential approaches to this, but all of them require significant changes to our cache lookup to allow it to update a cache entry that is outside of the specified search bases. We can't just do a standard LDAP search for the username or UID, because it will be looking in the wrong place. Instead we'd need to first search the cache to see if a fake user exists with that username, then use the originalDN attribute to look up the user.

Of course, there are issues with this too, if the username happens to be in use in different parts of the LDAP tree (i.e. you have a fake user that's outside the search base with the same name as a user that DOES exist inside the search base, but the fake user's group was looked up first).

It's a highly nontrivial problem and it requires a lot of thought and careful planning. Ticket #960 is the safe and least difficult solution at this time.

---

Comment from dpal at 2011-08-25 15:02:50

Fields changed

milestone: NEEDS_TRIAGE => SSSD Deferred

---

Comment from dpal at 2012-01-19 03:22:07

Fields changed

rhbz: => 0

---

Comment from prefect at 2017-02-24 14:48:36

Metadata Update from @prefect:

• Issue set to the milestone: SSSD Patches welcome

---

Comment from pbrezina at 2020-03-24 14:22:17

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

---

Comment from pbrezina at 2020-03-24 14:22:18

Metadata Update from @pbrezina:

• Issue close_status updated to: wontfix
• Issue status updated to: Closed (was: Open)