URL: https://github.com/SSSD/sssd/pull/5171 Author: pbrezina Title: #5171: files: allow root membership Action: opened
PR body: """ 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: https://github.com/SSSD/sssd/issues/5170 """
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5171/head:pr5171 git checkout pr5171
URL: https://github.com/SSSD/sssd/pull/5171 Title: #5171: files: allow root membership
sumit-bose commented: """ Hi,
I'm a bit reluctant here especially with allowing users with GID 0. I guess if it would be just about /etc/passwd and /etc/group it would be ok since those files are handled by nss_files as well and should be protected by the OS in the sense that they have proper permissions, owner, SELinux context, whatever, But the files provider an handle other passwd and group style files as well, `passwd_files` and `group_files` as well where the protection is unclear and we currently do not check permissions on those files.
So I wonder if it would not be better to just error out completely in case we find a user which is filtered out as a group-member and let nss_files handle the group. E.g.:
``` diff --git a/src/responder/nss/nss_protocol_grent.c b/src/responder/nss/nss_protocol_grent.c index 9c443d0..c604ee1 100644 --- a/src/responder/nss/nss_protocol_grent.c +++ b/src/responder/nss/nss_protocol_grent.c @@ -132,6 +132,7 @@ nss_protocol_fill_members(struct sss_packet *packet, uint8_t *body; errno_t ret; int i, j; + char *fq_name = NULL;
tmp_ctx = talloc_new(NULL); if (tmp_ctx == NULL) { @@ -159,6 +160,21 @@ nss_protocol_fill_members(struct sss_packet *packet, DEBUG(SSSDBG_TRACE_FUNC, "Group [%s] member [%s] filtered out! " "(negative cache)\n", group_name, member_name); + if (is_files_provider(domain)) { + fq_name = ldb_msg_find_attr_as_string(msg, SYSDB_NAME, + group_name); + DEBUG(SSSDBG_TRACE_FUNC, + "Adding files provider group [%s] to the " + "negative cache.\n", fq_name); + ret = sss_ncache_set_group(rctx->ncache, false, domain, + fq_name); + if (ret != EOK) { + DEBUG(SSSDBG_OP_FAILURE, + "sss_ncache_set_group failed.\n"); + } + ret = EEXIST; + goto done; + } continue; } } ```
The should solve the cases where root is a member of a group or a user with GID 0 is a member of the group. There is only a slight oddness since the user with GID 0 may or may not be in the negative cache when the group is looked up. If it is in the negative cache we error out and nss_files returns the group. If it is not in the negative cache it is added to the member list because it is stored as a ghost user and nss_sss returns the group. So it is a bit odd that it might be returned by nss_files or nss_sss but since in both cases it is the same content I think it is ok. There is only the case if explicitly only nss_sss is used the group will be returned or not depending on if the user was looked up shortly before and is in the negative cache or not. But I'm not sure if this is really an important use case.
I'm not sure if `When a user is part of root group - the membership is not returned` really is an issue, I wasn't able to reproduce this, do you have a reproducer?
bye, Sumit """
See the full comment at https://github.com/SSSD/sssd/pull/5171#issuecomment-642714671
sssd-devel@lists.fedorahosted.org
-
pbrezina -
sumit-bose