Bug 1473571

This is the tracker bug for the SSSD part of allowing flexible client timeouts.

Currently I have a patch where the timeout can be set by an environment variable. But the plan is to add a new API which allow the client to specific the timeout individually.

*** Bug 1434982 has been marked as a duplicate of this bug. ***

Upstream ticket:
https://pagure.io/SSSD/sssd/issue/2478

* master:
859bddc2bf51dc426a3dc56bd9f365e9c5722b65                                                                                                                                                                                                    
e54db68cbb9c12d8a6867f2c7766fb2115ab0997
85da8a5e90bffc8b0fef5e0ea364a8d3cb50de86
55f7d8034d783c01789d76a2b9ffc901045e8af8
a7d6ca275d6b2e5d396cbefb18d0ee880011e271
52e675ec4b160720515c81ae8c0e5a95feb50c57
ac6b267ff3df6d0417062a128ec16b184ea2c1b7
cf93f7c2f2031078bbbff095dae01eb4f8deff85
5e6622722e84d594298a8324f3685a1bda2b5868
7449b236523409cc8766fb957d6cba051fdfb483

verison:
ipa-server-4.5.4-6.el7.x86_64
sssd-1.16.0-9.el7.x86_64
389-ds-base-1.3.7.5-10.el7.x86_64

Followed steps given in c#13 on client and taken pstack of dirsrv on master.

pstack doesn't shows any thread in lock state.

Sumit, can you confirm if bug can be marked as verified.

You do not need a pstack of dirsrv here. If you see the 'Done [62].' after 1s with the test program (step 6) after SSSD's backend is stopped (step 5) you can mark this ticket as verified.

version:
ipa-server-4.5.4-6.el7.x86_64
sssd-1.16.0-9.el7.x86_64
389-ds-base-1.3.7.5-10.el7.x86_64

Actual result:
[root@client ~]# systemctl restart sssd
[root@client ~]# kill -STOP $(pidof sssd_be)
[root@client ~]# ./sss_nss_getpwnam_timeout_test  test303
Done [5].

Following steps from C#13 and C#16 and based on above observations marking the bug as verified.

IPA-server: ipa-server-4.5.4-7.el7.x86_64
SSSD version: sssd-1.16.0-14.el7.x86_64

Verified the bug on the basis of following commands:
 # setup IPA master with latest version , configure ad-trust with slapi-nis option enabled.

[root@auto-hv-01-guest03 ~]# ipa trust-find ipaad2016.test
---------------
1 trust matched
---------------
  Realm name: ipaad2016.test
  Domain NetBIOS name: IPAAD2016
  Domain Security Identifier: S-1-5-21-813110839-3732285123-1597101681
  Trust type: Active Directory domain
----------------------------
Number of entries returned 1
----------------------------
[root@auto-hv-01-guest03 ~]# sleep 60
[root@auto-hv-01-guest03 ~]# id administrator
uid=1577600500(administrator) gid=1577600500(administrator) groups=1577600500(administrator),1577600512(domain admins),1577600520(group policy creator owners),1577600513(domain users),1577600518(schema admins),1577600519(enterprise admins)

[root@auto-hv-01-guest03 ~]# vi /etc/sssd/sssd.conf
[root@auto-hv-01-guest03 ~]# systemctl restart sssd
[root@auto-hv-01-guest03 ~]# kill -STOP $(pidof sssd_be)
[root@auto-hv-01-guest03 ~]# ./sss_nss_getpwnam_timeout_test  test303
Done [5].

Thus on the basis of above observations, marking the bug status to "VERIFIED".

There was an additional hardening patch 3e32cb2ad36a9dd2654c7f63469dc595f1bb8593 that is also needed in RHEL. Therefore, I'm moving the bug to POST so we create the new build.

There are no additional steps needed to re-verify the bug, just doing the same that was done in comment #26 is sufficient.

I'm sorry for the late notice..

IPA-server: ipa-server-4.5.4-9.el7.x86_64
SSSD version: sssd-1.16.0-15.el7.x86_64

Verified the bug on the basis of following commands:
# Setup IPA master with latest version
# Configure 'ipa-adtrust-install' with slapi-nis option enabled (yes).


Observations:
------------------
[root@auto-hv-01-guest10 bz1473571]# ipa trust-find ipaad2016.test
---------------
1 trust matched
---------------
  Realm name: ipaad2016.test
  Domain NetBIOS name: IPAAD2016
  Domain Security Identifier: S-1-5-21-813110839-3732285123-1597101681
  Trust type: Active Directory domain
  UPN suffixes: upn2016.in, newad2016.test
----------------------------
Number of entries returned 1
----------------------------

[root@auto-hv-01-guest10 ~]# id administrator
uid=1577600500(administrator) gid=1577600500(administrator) groups=1577600500(administrator),1577600512(domain admins),1577600520(group policy creator owners),1577600513(domain users),1577600518(schema admins),1577600519(enterprise admins)

[root@auto-hv-01-guest10 bz1473571]# yum -y install libsss_nss_idmap-devel

[root@auto-hv-01-guest10 bz1473571]# gcc -Wall -Wextra -Werror sss_nss_getpwnam_timeout_test.c -o sss_nss_getpwnam_timeout_test -lsss_nss_idmap

[root@auto-hv-01-guest10 bz1473571]# ls -l
total 16
-rwxr-xr-x. 1 root root 8680 Jan 31 01:59 sss_nss_getpwnam_timeout_test
-rw-r--r--. 1 root root  529 Jan 31 01:54 sss_nss_getpwnam_timeout_test.c

[root@auto-hv-01-guest10 bz1473571]## Setting timeout = 999999 in sssd.conf 
[root@auto-hv-01-guest10 bz1473571]# vi /etc/sssd/sssd.conf
[root@auto-hv-01-guest10 bz1473571]# cat /etc/sssd/sssd.conf | grep timeout
timeout = 999999
memcache_timeout = 600
[root@auto-hv-01-guest10 bz1473571]# systemctl restart sssd
[root@auto-hv-01-guest10 bz1473571]# kill -STOP $(pidof sssd_be)
[root@auto-hv-01-guest10 bz1473571]# ./sss_nss_getpwnam_timeout_test  test303
Done [5].

Thus on the basis of above observations, marking the bug status to "VERIFIED".

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-2018:0929