RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1440132 - fiter_users and filter_groups stop working properly in v 1.15
Summary: fiter_users and filter_groups stop working properly in v 1.15
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Niranjan Mallapadi Raghavender
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-07 11:12 UTC by Jakub Hrozek
Modified: 2020-05-02 18:39 UTC (History)
10 users (show)

Fixed In Version: sssd-1.15.2-43.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 09:04:18 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4392 0 None closed fiter_users and filter_groups stop working properly in v 1.15 2020-09-03 16:12:01 UTC
Red Hat Product Errata RHEA-2017:2294 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2017-08-01 12:39:55 UTC

Description Jakub Hrozek 2017-04-07 11:12:11 UTC 
This bug is created as a clone of upstream ticket:
https://pagure.io/SSSD/sssd/issue/3362

After upgrade from 1.14 to 1.15 I noticed odd behavior of filter_* settings
If local user or group absent this works fine and prevents accounts that exist in LDAP from showing up in the host
Example of config:

    # grep named /etc/sssd/sssd.conf 
    filter_users = avahi,dbus,haldaemon,ldap,named,news,nscd,radiusd,root
    filter_groups = named,stapdev,stapusr,uuidd

    # grep sss /etc/nsswitch.conf
    passwd:     files sss
    shadow:     files sss
    group:      files sss


Now without local named account the user does not exist as expected:

    # grep named /etc/passwd /etc/group 
    # id named
    id: named: no such user

However, both user and group named still show up as enumerated "leaking:" from LDAP

    # getent passwd named
    # getent passwd | grep named:
    named:*:25:25:Service Account named:/var/named:/bin/bash
    # getent group  named
    # getent group  | grep named
    named:*:25:


Now, trying to add local user with running SSSD causes error and weird behavior. the user appears to be created but yet not found in local files.

    # useradd -u 25 named
    useradd: UID 25 is not unique
    # getent passwd 25
    named:*:25:25:Service Account named:/var/named:/bin/bash
    # getent passwd named
    named:*:25:25:Service Account named:/var/named:/bin/bash
    # grep named /etc/passwd
    # id named
    uid=25(named) gid=25(named) groups=25(named)
    # grep named /etc/passwd  /etc/group
    # 

 After sssd restart it disappears

    # service sssd restart
    Redirecting to /bin/systemctl restart  sssd.service
    # id named
    id: named: no such user

After downgrade to sssd 1.14 all works as expected and user/group named never shows up from LDAP

[![sssd.conf](/SSSD/sssd/issue/raw/files/134205d6c25db2201b743351f39cbe2c8e75e0b8311f6c4f81904cdd11f8af86-sssd.conf)](/SSSD/sssd/issue/raw/files/134205d6c25db2201b743351f39cbe2c8e75e0b8311f6c4f81904cdd11f8af86-sssd.conf)
Comment 4 Jakub Hrozek 2017-05-10 13:15:15 UTC 
* master:
 * e1052a50b9cf42963e0a805a43e2957426096938
 * 4ef0b19a5e8a327443d027e57487c8a1e4f654ce
 * 180e0b282be6aeb047c4b24b46e0b56afba1fdc8
 * f24ee5cca4cd43e7edf26fec453fbd99392bbe4b
 * a012a71f21bf1a4687e58085f19c18cc5b2bbadd
Comment 6 Lukas Slebodnik 2017-05-17 13:19:18 UTC 
There is still a bug https://pagure.io/SSSD/sssd/issue/3362#comment-441090
Comment 7 Sumit Bose 2017-05-17 14:28:35 UTC 
* master:
  * 6a1da829eaa1eee3e854f0cadc0b6effff776ab4

fixes a '6a1da829eaa1eee3e854f0cadc0b6effff776ab4' in the patch set above
Comment 8 Sumit Bose 2017-05-17 14:32:38 UTC 
(In reply to Sumit Bose from comment #7)
> * master:
>   * 6a1da829eaa1eee3e854f0cadc0b6effff776ab4
> 
> fixes a '6a1da829eaa1eee3e854f0cadc0b6effff776ab4' in the patch set above

sorry I meant 'may be used uninitialized in this function' compiler error.
Comment 9 Lukas Slebodnik 2017-06-05 15:29:02 UTC 
master:
* 13205258cc17d3833558244251f5adbc98cf34e5
* 4c09cd008967c5c0ec358dc658ffc6fc1cef2697
* c8193b1602cf44740b59f5dfcdc5330508c0c365
Comment 11 Amith 2017-06-27 04:59:24 UTC 
Verified the bug on SSSD version: sssd-1.15.2-49.el7.x86_64

Steps followed during verification:

1. Reproduce the bug with an older sssd build like sssd-1.15.1-1.el7.x86_64

2. Install the above old build and create a user-group in ldap server.

3. Filter them out in the NSS section. Example:

[nss]
debug_level = 0xFFF0
filter_users = testuser1
filter_groups = TestGroup

4. Clear the cache and restart sssd service.

5. Run the following commands:

 # id 2121
uid=2121(testuser1) gid=2121 groups=2121

 # getent passwd -s sss testuser1
testuser1:*:2121:2121:testuser1:/home/testuser1:/bin/bash

# getent passwd -s sss TestGroup

# getent group -s sss 23011
TestGroup:*:23011:

# getent passwd -s sss TestGroup

# rpm -q sssd
sssd-1.15.1-1.el7.x86_64

6. As seen from the output of above commands, the older sssd build fetched the filtered (blocked) testuser1 and TestGroup. The trick is to fetch them using their UID's first.

7. Upgrade the sssd to latest version: sssd-1.15.2-49

8. Repeat step 5 and see the results.

# id 2121
id: 2121: no such user
 
# getent passwd -s sss testuser1

# getent group -s sss 23011

# getent passwd -s sss TestGroup

# rpm -q sssd
sssd-1.15.2-49.el7.x86_64

The bug appears to be fixed.
Comment 12 errata-xmlrpc 2017-08-01 09:04:18 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:2294
Note You need to log in before you can comment on or make changes to this bug.