Bug 1440132

Summary:	fiter_users and filter_groups stop working properly in v 1.15
Product:	Red Hat Enterprise Linux 7	Reporter:	Jakub Hrozek <jhrozek>
Component:	sssd	Assignee:	SSSD Maintainers <sssd-maint>
Status:	CLOSED ERRATA	QA Contact:	Niranjan Mallapadi Raghavender <mniranja>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	apeetham, grajaiya, jhrozek, lslebodn, mkosek, mzidek, pbrezina, sbose, sgoveas, tscherf
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.15.2-43.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-01 09:04:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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