-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSSD must be able to resolve membership involving root with files provider #5170
Labels
Comments
pbrezina
added a commit
to pbrezina/sssd
that referenced
this issue
May 20, 2020
SSSD design decision was to "never handle root" and we use uid=0 and gid=0 to indicate various error states. root user and group is unconditionally added in negative cache. This makes perfect sense for LDAP but introduced regressions in files provider when compared to nss_files: 1) When a user is part of root group - the membership is not returned 2) When a user has root as primary group - the user is not returned and every other membership is broken. The "never handle root" policy is basically kept, with few exceptions for files provider: - it will not filter out root as group member if it is also files provider - solves 1) - it will store user with gid=0 unless it also has uid=0 thus solving 2) Direct request for root user or group will still not be handled. Resolves: SSSD#5170
pbrezina
added a commit
to pbrezina/sssd
that referenced
this issue
Jun 23, 2020
SSSD design decision was to "never handle root" and we use uid=0 and gid=0 to indicate various error states. root user and group is unconditionally added in negative cache. This makes perfect sense for LDAP but introduced regressions in files provider when compared to nss_files: 1) When a user is part of root group - the membership is not returned 2) When a user has root as primary group - the user is not returned and every other membership is broken. The "never handle root" policy is basically kept, with few exceptions for files provider: - it will not filter out root as group member if it is also files provider - solves 1) - it will store user with gid=0 unless it also has uid=0 thus solving 2) Direct request for root user or group will still not be handled. Resolves: SSSD#5170
pbrezina
added a commit
to pbrezina/sssd
that referenced
this issue
Jun 23, 2020
There are two use cases that do not work with files provider: 1. User has primary GID 0: This is fine by itself since SSSD does not store this user in cache and it is handled only by `nss_files` so the user (`tuser`) is returned correctly. The problem is when you try to resolve group that the user is member of. In this case that the membership is missing the group (but only if the user was previously resolved and thus stored in negative cache). ``` tuser:x:1001:0::/home/tuser:/bin/bash tuser:x:1001:tuser // tuser@files is ghost member of the group so it is returned because it is not in negative cache $ getent group tuser tuser:x:1001:tuser // expire memcache // tuser@files is ghost member but not returned because it is in negative cache $ id tuser // returned from nss_files uid=1001(tuser) gid=0(root) groups=0(root),1001(tuser) [pbrezina /dev/shm/sssd]$ getent group tuser tuser:x:1001: ``` **2. root is member of other group** The root member is missing from the membership since it was filtered out by negative cache. ``` tuser:x:1001:root $ id root uid=0(root) gid=0(root) groups=0(root),1001(tuser) [pbrezina /dev/shm/sssd]$ getent group tuser tuser:x:1001: ``` In files provider, only the users that we do not want to managed are stored as ghost member, therefore we can let nss_files handle group that has ghost members. Resolves: SSSD#5170
pbrezina
added a commit
to pbrezina/sssd
that referenced
this issue
Jun 24, 2020
There are two use cases that do not work with files provider: 1. User has primary GID 0: This is fine by itself since SSSD does not store this user in cache and it is handled only by `nss_files` so the user (`tuser`) is returned correctly. The problem is when you try to resolve group that the user is member of. In this case that the membership is missing the group (but only if the user was previously resolved and thus stored in negative cache). ``` tuser:x:1001:0::/home/tuser:/bin/bash tuser:x:1001:tuser // tuser@files is ghost member of the group so it is returned because it is not in negative cache $ getent group tuser tuser:x:1001:tuser // expire memcache // tuser@files is ghost member but not returned because it is in negative cache $ id tuser // returned from nss_files uid=1001(tuser) gid=0(root) groups=0(root),1001(tuser) [pbrezina /dev/shm/sssd]$ getent group tuser tuser:x:1001: ``` **2. root is member of other group** The root member is missing from the membership since it was filtered out by negative cache. ``` tuser:x:1001:root $ id root uid=0(root) gid=0(root) groups=0(root),1001(tuser) [pbrezina /dev/shm/sssd]$ getent group tuser tuser:x:1001: ``` In files provider, only the users that we do not want to managed are stored as ghost member, therefore we can let nss_files handle group that has ghost members. Tests are changed as well to work with this behavior. Users are added when required and ghost are expected to return ENOENT. Resolves: SSSD#5170
pbrezina
added a commit
to pbrezina/sssd
that referenced
this issue
Jun 24, 2020
There are two use cases that do not work with files provider: 1. User has primary GID 0: This is fine by itself since SSSD does not store this user in cache and it is handled only by `nss_files` so the user (`tuser`) is returned correctly. The problem is when you try to resolve group that the user is member of. In this case that the membership is missing the group (but only if the user was previously resolved and thus stored in negative cache). ``` tuser:x:1001:0::/home/tuser:/bin/bash tuser:x:1001:tuser // tuser@files is ghost member of the group so it is returned because it is not in negative cache $ getent group tuser tuser:x:1001:tuser // expire memcache // tuser@files is ghost member but not returned because it is in negative cache $ id tuser // returned from nss_files uid=1001(tuser) gid=0(root) groups=0(root),1001(tuser) [pbrezina /dev/shm/sssd]$ getent group tuser tuser:x:1001: ``` **2. root is member of other group** The root member is missing from the membership since it was filtered out by negative cache. ``` tuser:x:1001:root $ id root uid=0(root) gid=0(root) groups=0(root),1001(tuser) [pbrezina /dev/shm/sssd]$ getent group tuser tuser:x:1001: ``` In files provider, only the users that we do not want to managed are stored as ghost member, therefore we can let nss_files handle group that has ghost members. Tests are changed as well to work with this behavior. Users are added when required and ghost are expected to return ENOENT. Resolves: SSSD#5170
pbrezina
added a commit
to pbrezina/sssd
that referenced
this issue
Jun 25, 2020
There are two use cases that do not work with files provider: 1. User has primary GID 0: This is fine by itself since SSSD does not store this user in cache and it is handled only by `nss_files` so the user (`tuser`) is returned correctly. The problem is when you try to resolve group that the user is member of. In this case that the membership is missing the group (but only if the user was previously resolved and thus stored in negative cache). ``` tuser:x:1001:0::/home/tuser:/bin/bash tuser:x:1001:tuser // tuser@files is ghost member of the group so it is returned because it is not in negative cache $ getent group tuser tuser:x:1001:tuser // expire memcache // tuser@files is ghost member but not returned because it is in negative cache $ id tuser // returned from nss_files uid=1001(tuser) gid=0(root) groups=0(root),1001(tuser) [pbrezina /dev/shm/sssd]$ getent group tuser tuser:x:1001: ``` **2. root is member of other group** The root member is missing from the membership since it was filtered out by negative cache. ``` tuser:x:1001:root $ id root uid=0(root) gid=0(root) groups=0(root),1001(tuser) [pbrezina /dev/shm/sssd]$ getent group tuser tuser:x:1001: ``` In files provider, only the users that we do not want to managed are stored as ghost member, therefore we can let nss_files handle group that has ghost members. Tests are changed as well to work with this behavior. Users are added when required and ghost are expected to return ENOENT. Resolves: SSSD#5170
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 8): Bug 1794607
The text was updated successfully, but these errors were encountered: