Bug 1921315

Summary: Unexpected interaction between overriding the primary group and the 'auto_private_groups = true' option
Product: Red Hat Enterprise Linux 8 Reporter: Rakesh Kumar <rakkumar>
Component: sssdAssignee: Sumit Bose <sbose>
Status: NEW --- QA Contact: sssd-qe
Severity: high Docs Contact:
Priority: unspecified    
Version: 8.4CC: aboscatt, atikhono, chaithco, grajaiya, jwooten, lslebodn, mzidek, pbrezina, rgarcia, sbose, tscherf
Target Milestone: betaKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Rakesh Kumar 2021-01-27 21:19:32 UTC
Description of problem:Unexpected interaction between overriding the primary group and the 'auto_private_groups = true' option

------------------------------------------------------

The first lookup is with the original primary GID of the user but due
to the override it is returned with the overridden primary GID which is
wrong. Unfortunately the memory cache save the GID with the wrong group
name for some time before it can be refreshed and as a result the lookup
with the new GID also returns the wrong name.
-----------------------------------------------------------


Version-Release number of selected component (if applicable): sssd-1.16.5-10.el7_9.5.x86_64 


How reproducible:


Steps to Reproduce:
1. 

[root@ipaserver ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.9 (Maipo)

2.

 # rpm -qa | grep -i sssd
python-sssdconfig-1.16.5-10.el7_9.6.noarch
sssd-client-1.16.5-10.el7_9.6.x86_64
sssd-krb5-common-1.16.5-10.el7_9.6.x86_64
sssd-kcm-1.16.5-10.el7_9.6.x86_64
sssd-dbus-1.16.5-10.el7_9.6.x86_64
sssd-ipa-1.16.5-10.el7_9.6.x86_64
sssd-common-1.16.5-10.el7_9.6.x86_64
sssd-ad-1.16.5-10.el7_9.6.x86_64
sssd-krb5-1.16.5-10.el7_9.6.x86_64
sssd-proxy-1.16.5-10.el7_9.6.x86_64
sssd-polkit-rules-1.16.5-10.el7_9.6.x86_64
sssd-libwbclient-1.16.5-10.el7_9.6.x86_64
sssd-ldap-1.16.5-10.el7_9.6.x86_64
sssd-1.16.5-10.el7_9.6.x86_64
sssd-winbind-idmap-1.16.5-10.el7_9.6.x86_64
sssd-common-pac-1.16.5-10.el7_9.6.x86_64
sssd-tools-1.16.5-10.el7_9.6.x86_64

3. Before applying overrides

---
[root@ipaserver ~]# id testuser80
uid=974001183(testuser80) gid=974001183(testuser80) groups=974001183(testuser80),974000513(domain users),974001212(testgroup)

---


4. After Applying override

---

[root@ipaserver ~]# getent -s sss group testuser90 <-- Group which I am going to use for override
testuser90:*:974001219:


[root@ipaserver ~]# sss_override user-add testuser80 -g 974001219 <------- Applied override
SSSD needs to be restarted for the changes to take effect.

[root@ipaserver ~]# systemctl restart sssd

[root@ipaserver ~]# id testuser80
uid=974001183(testuser80) gid=974001219(testuser90) groups=974001219(testuser90),974001212(testgroup),974000513(domain users)

---

5. File ownership after override

---
[testuser80@ipaserver ~]$ ls -l
total 0
drwxr-xr-x. 2 testuser80 testuser90 6 Jan 26 13:02 test2override <----- see this ... grouppermission as the override group

---

6. After sometime ..

---

[root@ipaserver ~]# ./perm_check.sh 
total 0
drwxr-xr-x. 2 testuser80 testuser90 6 Jan 26 13:02 test2override
total 0
drwxr-xr-x. 2 testuser80 testuser90 6 Jan 26 13:02 test2override
total 0
drwxr-xr-x. 2 testuser80 testuser90 6 Jan 26 13:02 test2override
total 0
drwxr-xr-x. 2 testuser80 testuser90 6 Jan 26 13:02 test2override
total 0
drwxr-xr-x. 2 testuser80 testuser90 6 Jan 26 13:02 test2override
total 0
drwxr-xr-x. 2 testuser80 testuser80 6 Jan 26 13:02 test2override <-------- See it changed here.
total 0
drwxr-xr-x. 2 testuser80 testuser80 6 Jan 26 13:02 test2override
total 0
drwxr-xr-x. 2 testuser80 testuser80 6 Jan 26 13:02 test2override


----

FYI, Issue is only reproducible if you set auto_private_groups= true

-------------------------------

[sssd]
domains = gsslab1.idm.global
config_file_version = 2
services = nss, pam

[domain/gsslab1.idm.global]
ad_domain = gsslab1.idm.global
krb5_realm = GSSLAB1.IDM.GLOBAL
realmd_tags = manages-system joined-with-adcli 
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
override_homedir = /home/%u@%d
auto_private_groups = true
access_provider = ad
[root@ipaserver ~]# 
--------------------------------------------------

Actual results: Unexpected interaction between overriding the primary group and the 'auto_private_groups = true' option

Note: after applying sss_override option , after 10min/15 min , primary group got chnaged

for example:
sss_override user-add testuser80 -g 974001219
 
And in result: it shows

drwxr-xr-x. 2 testuser80 testuser80 6 Jan 26 13:02 test2override 

Expected results: But it should show like this::

total 0
drwxr-xr-x. 2 testuser80 testuser90 6 Jan 26 13:02 test2override

Additional info:

Customer's application requires service accounts (defined in AD) to have a common primary group, and end users have private groups

Comment 5 Sumit Bose 2021-01-28 07:39:02 UTC
Hi,

A shorter reproducer is to call

    getent group 974001183
    getent group 974001212

after changing the primary group to 974001212 and restarting SSSD on the
your test system. I get:

    [root@ipaserver ~]# getent -s sss group 974001183
    testuser80:*:974001212:
    [root@ipaserver ~]# getent -s sss group 974001212
    testuser80:*:974001212:

The first lookup is with the original primary GID of the user but due
to the override it is returned with the overridden primary GID which is
wrong. Unfortunately the memory cache save the GID with the wrong group
name for some time before it can be refreshed and as a result the lookup
with the new GID also returns the wrong name.


bye,
Sumit

Comment 6 Ric Garcia 2021-02-01 15:41:13 UTC
Upon inspection CNV is not dependent upon this bug. Please add us again if you deem so.