Hi,
the attached patch fixes https://fedorahosted.org/sssd/ticket/2724 for me. I haven't yet heard back from the affected user, but they do have test packages available.
On Tue, Jul 21, 2015 at 09:41:46PM +0200, Jakub Hrozek wrote:
Hi,
the attached patch fixes https://fedorahosted.org/sssd/ticket/2724 for me. I haven't yet heard back from the affected user, but they do have test packages available.
The patch is working as expected and fixes the issue for me as well.
Although it might not look as the most elegant way I think the approach is ok because otherwise we would be to check for every group by GID request if the GID might belong to a MPG which would require a user lookup. This would slow down the requests where the GID belong to a normal (non-MPG) group.
Nevertheless I wonder if we should check if the group name matches the user name before deleting the group by GID to be on the safe side?
bye, Sumit
From b02129c29b35ff74aff537955ed3d38d477b9f3b Mon Sep 17 00:00:00 2001 From: Jakub Hrozek jhrozek@redhat.com Date: Tue, 21 Jul 2015 11:44:03 +0200 Subject: [PATCH] IPA: Remove MPG groups if getgrgid was called before getpw()
https://fedorahosted.org/sssd/ticket/2724
This bug only affects IPA clients that are connected to IPA servers with AD trust and ID mapping in effect.
If an IPA client calls getgrgid() for an ID that matches a user, the user's private group would be returned and stored as a group entry.
Subsequent queries for that user would fail, because MPG domains impose uniqueness restriction for both the ID and name space across groups and users.
To work around that, we remove the UPG groups in MPG domains during a group lookup.
src/providers/ipa/ipa_s2n_exop.c | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/src/providers/ipa/ipa_s2n_exop.c b/src/providers/ipa/ipa_s2n_exop.c index 812a4bbd707faf5c184594b562c148d1e704fd58..88ae41f89c405966b61143d69cf5831ef8a50db2 100644 --- a/src/providers/ipa/ipa_s2n_exop.c +++ b/src/providers/ipa/ipa_s2n_exop.c @@ -2005,8 +2005,35 @@ static errno_t ipa_s2n_save_objects(struct sss_domain_info *dom, attrs->a.user.pw_dir, attrs->a.user.pw_shell, NULL, attrs->sysdb_attrs, NULL, timeout, now);
if (ret != EOK) {DEBUG(SSSDBG_OP_FAILURE, "sysdb_store_user failed.\n");
if (ret == EEXIST && dom->mpg == true) {/* This handles the case where getgrgid() was called for* this user, so a group was created in the cache*/ret = sysdb_delete_group(dom, NULL, attrs->a.user.pw_uid);if (ret != EOK) {DEBUG(SSSDBG_OP_FAILURE,"sysdb_delete_group failed for MPG group [%d]: %s\n",ret, sss_strerror(ret));goto done;}ret = sysdb_store_user(dom, name, NULL,attrs->a.user.pw_uid,gid, attrs->a.user.pw_gecos,attrs->a.user.pw_dir,attrs->a.user.pw_shell,NULL, attrs->sysdb_attrs, NULL,timeout, now);if (ret != EOK) {DEBUG(SSSDBG_OP_FAILURE,"sysdb_store_user failed for MPG user [%d]: %s\n",ret, sss_strerror(ret));goto done;}} else if (ret != EOK) {DEBUG(SSSDBG_OP_FAILURE,"sysdb_store_user failed [%d]: %s\n",ret, sss_strerror(ret)); goto done; }-- 2.4.3
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, Jul 22, 2015 at 10:01:31AM +0200, Sumit Bose wrote:
On Tue, Jul 21, 2015 at 09:41:46PM +0200, Jakub Hrozek wrote:
Hi,
the attached patch fixes https://fedorahosted.org/sssd/ticket/2724 for me. I haven't yet heard back from the affected user, but they do have test packages available.
The patch is working as expected and fixes the issue for me as well.
Although it might not look as the most elegant way I think the approach is ok because otherwise we would be to check for every group by GID request if the GID might belong to a MPG which would require a user lookup. This would slow down the requests where the GID belong to a normal (non-MPG) group.
Nevertheless I wonder if we should check if the group name matches the user name before deleting the group by GID to be on the safe side?
OK, done.
btw the function is really long. Would you oppose to splitting it into smaller functions that save user/group/... ?
(We need tests for that, though..)
On Wed, Jul 22, 2015 at 12:18:07PM +0200, Jakub Hrozek wrote:
On Wed, Jul 22, 2015 at 10:01:31AM +0200, Sumit Bose wrote:
On Tue, Jul 21, 2015 at 09:41:46PM +0200, Jakub Hrozek wrote:
Hi,
the attached patch fixes https://fedorahosted.org/sssd/ticket/2724 for me. I haven't yet heard back from the affected user, but they do have test packages available.
The patch is working as expected and fixes the issue for me as well.
Although it might not look as the most elegant way I think the approach is ok because otherwise we would be to check for every group by GID request if the GID might belong to a MPG which would require a user lookup. This would slow down the requests where the GID belong to a normal (non-MPG) group.
Nevertheless I wonder if we should check if the group name matches the user name before deleting the group by GID to be on the safe side?
OK, done.
Thank you. The patch looks good and is working as advertised, ACK.
btw the function is really long. Would you oppose to splitting it into smaller functions that save user/group/... ?
(We need tests for that, though..)
no, feel free to open tickets to track this.
bye, Sumit
On Thu, Jul 30, 2015 at 06:20:31PM +0200, Sumit Bose wrote:
On Wed, Jul 22, 2015 at 12:18:07PM +0200, Jakub Hrozek wrote:
On Wed, Jul 22, 2015 at 10:01:31AM +0200, Sumit Bose wrote:
On Tue, Jul 21, 2015 at 09:41:46PM +0200, Jakub Hrozek wrote:
Hi,
the attached patch fixes https://fedorahosted.org/sssd/ticket/2724 for me. I haven't yet heard back from the affected user, but they do have test packages available.
The patch is working as expected and fixes the issue for me as well.
Although it might not look as the most elegant way I think the approach is ok because otherwise we would be to check for every group by GID request if the GID might belong to a MPG which would require a user lookup. This would slow down the requests where the GID belong to a normal (non-MPG) group.
Nevertheless I wonder if we should check if the group name matches the user name before deleting the group by GID to be on the safe side?
OK, done.
Thank you. The patch looks good and is working as advertised, ACK.
sorry, forgot to say that CI is still running, I'll send the result when it is done.
bye, Sumit
btw the function is really long. Would you oppose to splitting it into smaller functions that save user/group/... ?
(We need tests for that, though..)
no, feel free to open tickets to track this.
bye, Sumit _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Thu, Jul 30, 2015 at 06:23:03PM +0200, Sumit Bose wrote:
On Thu, Jul 30, 2015 at 06:20:31PM +0200, Sumit Bose wrote:
On Wed, Jul 22, 2015 at 12:18:07PM +0200, Jakub Hrozek wrote:
On Wed, Jul 22, 2015 at 10:01:31AM +0200, Sumit Bose wrote:
On Tue, Jul 21, 2015 at 09:41:46PM +0200, Jakub Hrozek wrote:
Hi,
the attached patch fixes https://fedorahosted.org/sssd/ticket/2724 for me. I haven't yet heard back from the affected user, but they do have test packages available.
The patch is working as expected and fixes the issue for me as well.
Although it might not look as the most elegant way I think the approach is ok because otherwise we would be to check for every group by GID request if the GID might belong to a MPG which would require a user lookup. This would slow down the requests where the GID belong to a normal (non-MPG) group.
Nevertheless I wonder if we should check if the group name matches the user name before deleting the group by GID to be on the safe side?
OK, done.
Thank you. The patch looks good and is working as advertised, ACK.
sorry, forgot to say that CI is still running, I'll send the result when it is done.
CI basically passed http://sssd-ci.duckdns.org/logs/job/20/16/summary.html
There is an unrealted issue in rawhide:
RPM build errors: error: Empty %files file /builddir/build/BUILD/sssd-1.13.1/sssd_client.lang
For details see http://sssd-ci.duckdns.org/logs/job/20/16/fedora_rawhide/ci-build-debug/ci-m...
so once again, ACK.
bye, Sumit
btw the function is really long. Would you oppose to splitting it into smaller functions that save user/group/... ?
(We need tests for that, though..)
no, feel free to open tickets to track this.
bye, Sumit _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Thu, Jul 30, 2015 at 06:20:31PM +0200, Sumit Bose wrote:
On Wed, Jul 22, 2015 at 12:18:07PM +0200, Jakub Hrozek wrote:
On Wed, Jul 22, 2015 at 10:01:31AM +0200, Sumit Bose wrote:
On Tue, Jul 21, 2015 at 09:41:46PM +0200, Jakub Hrozek wrote:
Hi,
the attached patch fixes https://fedorahosted.org/sssd/ticket/2724 for me. I haven't yet heard back from the affected user, but they do have test packages available.
The patch is working as expected and fixes the issue for me as well.
Although it might not look as the most elegant way I think the approach is ok because otherwise we would be to check for every group by GID request if the GID might belong to a MPG which would require a user lookup. This would slow down the requests where the GID belong to a normal (non-MPG) group.
Nevertheless I wonder if we should check if the group name matches the user name before deleting the group by GID to be on the safe side?
OK, done.
Thank you. The patch looks good and is working as advertised, ACK.
master: 6fe057efb981ee4b45dcadf131c03f8501fce28d
btw the function is really long. Would you oppose to splitting it into smaller functions that save user/group/... ?
(We need tests for that, though..)
no, feel free to open tickets to track this.
On Fri, Jul 31, 2015 at 10:26:58AM +0200, Jakub Hrozek wrote:
On Thu, Jul 30, 2015 at 06:20:31PM +0200, Sumit Bose wrote:
On Wed, Jul 22, 2015 at 12:18:07PM +0200, Jakub Hrozek wrote:
On Wed, Jul 22, 2015 at 10:01:31AM +0200, Sumit Bose wrote:
On Tue, Jul 21, 2015 at 09:41:46PM +0200, Jakub Hrozek wrote:
Hi,
the attached patch fixes https://fedorahosted.org/sssd/ticket/2724 for me. I haven't yet heard back from the affected user, but they do have test packages available.
The patch is working as expected and fixes the issue for me as well.
Although it might not look as the most elegant way I think the approach is ok because otherwise we would be to check for every group by GID request if the GID might belong to a MPG which would require a user lookup. This would slow down the requests where the GID belong to a normal (non-MPG) group.
Nevertheless I wonder if we should check if the group name matches the user name before deleting the group by GID to be on the safe side?
OK, done.
Thank you. The patch looks good and is working as advertised, ACK.
master: 6fe057efb981ee4b45dcadf131c03f8501fce28d
I would like to push the patch to sssd-1-12 as well if nobody opposes.
On (14/09/15 11:59), Jakub Hrozek wrote:
On Fri, Jul 31, 2015 at 10:26:58AM +0200, Jakub Hrozek wrote:
On Thu, Jul 30, 2015 at 06:20:31PM +0200, Sumit Bose wrote:
On Wed, Jul 22, 2015 at 12:18:07PM +0200, Jakub Hrozek wrote:
On Wed, Jul 22, 2015 at 10:01:31AM +0200, Sumit Bose wrote:
On Tue, Jul 21, 2015 at 09:41:46PM +0200, Jakub Hrozek wrote:
Hi,
the attached patch fixes https://fedorahosted.org/sssd/ticket/2724 for me. I haven't yet heard back from the affected user, but they do have test packages available.
The patch is working as expected and fixes the issue for me as well.
Although it might not look as the most elegant way I think the approach is ok because otherwise we would be to check for every group by GID request if the GID might belong to a MPG which would require a user lookup. This would slow down the requests where the GID belong to a normal (non-MPG) group.
Nevertheless I wonder if we should check if the group name matches the user name before deleting the group by GID to be on the safe side?
OK, done.
Thank you. The patch looks good and is working as advertised, ACK.
master: 6fe057efb981ee4b45dcadf131c03f8501fce28d
I would like to push the patch to sssd-1-12 as well if nobody opposes.
Sure, go ahead
LS
On Fri, Sep 18, 2015 at 10:52:05AM +0200, Lukas Slebodnik wrote:
On (14/09/15 11:59), Jakub Hrozek wrote:
On Fri, Jul 31, 2015 at 10:26:58AM +0200, Jakub Hrozek wrote:
On Thu, Jul 30, 2015 at 06:20:31PM +0200, Sumit Bose wrote:
On Wed, Jul 22, 2015 at 12:18:07PM +0200, Jakub Hrozek wrote:
On Wed, Jul 22, 2015 at 10:01:31AM +0200, Sumit Bose wrote:
On Tue, Jul 21, 2015 at 09:41:46PM +0200, Jakub Hrozek wrote: > Hi, > > the attached patch fixes https://fedorahosted.org/sssd/ticket/2724 for > me. I haven't yet heard back from the affected user, but they do have > test packages available.
The patch is working as expected and fixes the issue for me as well.
Although it might not look as the most elegant way I think the approach is ok because otherwise we would be to check for every group by GID request if the GID might belong to a MPG which would require a user lookup. This would slow down the requests where the GID belong to a normal (non-MPG) group.
Nevertheless I wonder if we should check if the group name matches the user name before deleting the group by GID to be on the safe side?
OK, done.
Thank you. The patch looks good and is working as advertised, ACK.
master: 6fe057efb981ee4b45dcadf131c03f8501fce28d
I would like to push the patch to sssd-1-12 as well if nobody opposes.
Sure, go ahead
LS
* sssd-1-12: 7cac5068960ae53ea91cb1b304b4c697c5dca547
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Sumit Bose