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: CLOSED MIGRATED 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: MigratedToJIRA, Triaged
Target Release: ---Flags: pm-rhel: mirror+
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: 2023-09-18 23:52:57 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:
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.

Comment 15 RHEL Program Management 2023-09-18 23:47:54 UTC
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 16 RHEL Program Management 2023-09-18 23:52:57 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.