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 - Group membership in output of "id" command is incomplete after setting filter_users_in_groups to false
Summary: Group membership in output of "id" command is incomplete after setting filter...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.8
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Pavel Březina
QA Contact: Steeve Goveas
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-26 14:08 UTC by Kristof Van Damme
Modified: 2016-08-11 08:58 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-11 08:58:56 UTC


Attachments (Terms of Use)
sssd.conf (deleted)
2016-07-26 14:56 UTC, Kristof Van Damme
no flags Details
log files (sssd_nss.log and sssd_default.log) (deleted)
2016-07-26 15:03 UTC, Kristof Van Damme
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.