Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1360367

Summary: Group membership in output of "id" command is incomplete after setting filter_users_in_groups to false
Product: Red Hat Enterprise Linux 6 Reporter: Kristof Van Damme <kristof.van.damme.ext>
Component: sssdAssignee: Pavel Březina <pbrezina>
Status: CLOSED NOTABUG QA Contact: Steeve Goveas <sgoveas>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.8CC: grajaiya, jhrozek, kristof.van.damme.ext, lslebodn, mkosek, mzidek, pbrezina, sssd-maint
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-11 08:58:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
sssd.conf
none
log files (sssd_nss.log and sssd_default.log) none

Description Kristof Van Damme 2016-07-26 14:08:38 UTC
Description of problem:

When setting filter_users_in_groups to "false" group membership does not work as expected.


Version-Release number of selected component (if applicable): 
1.13.3-22.el6


How reproducible:

Steps to Reproduce:
1. Create a local user, say "jboss" with uid 185 and group/gid jboss/185
2. Put "jboss" in "filter_users" list in sssd.conf (it exists also in the LDAP backend but we don't want to use it)
3. Add "jboss" as a member of a group that exists in the LDAP backend, say "support" with gid 1004367

Actual results:
# id jboss
uid=185(jboss) gid=185(jboss) groups=185(jboss)

Expected results:
# id jboss
uid=185(jboss) gid=185(jboss) groups=185(jboss),1004367(support)


Additional info:

Interestingly:
# su - jboss
$ id
uid=185(jboss) gid=185(jboss) groups=185(jboss)
$ newgrp gnasupport
$ id
uid=185(jboss) gid=1004367(support) groups=1004367(support),185(jboss)

This is inconsistent: the "id" command initially doesn't show the "support" group, but the "newgrp" command still allows making it the primary group. After that the "id" command shows the correct group membership.

Comment 1 Kristof Van Damme 2016-07-26 14:12:25 UTC
"newgrp gnasupport" => "newgrp support"

Comment 2 Jakub Hrozek 2016-07-26 14:47:14 UTC
Can you add your sssd.conf and the sssd logs as described in https://fedorahosted.org/sssd/wiki/Reporting_sssd_bugs

Comment 3 Kristof Van Damme 2016-07-26 14:56:27 UTC
Created attachment 1184297 [details]
sssd.conf

Comment 4 Kristof Van Damme 2016-07-26 15:03:34 UTC
Created attachment 1184309 [details]
log files (sssd_nss.log and sssd_default.log)

Comment 8 Pavel Březina 2016-08-11 08:58:56 UTC
I can reproduce this in house.

Since the user is permanently stored in the negative cache we do not perform initgroups for it.

Because filter_users_in_groups is set to false, GETGRNAM/GETGRID requests will yield filtered user as a member of this group. Because newgrp performs GETGRNAM lookup, the users is allowed to join this group.

This is not a bug, but rather intentional behaviour of filter_users_in_groups.