July 2022 - Sssd-maintainers - Fedora mailing-lists

[Bug 2111582] virtqemud deadlocking
by bugzilla＠redhat.com 30 Jul '22

30 Jul '22

https://bugzilla.redhat.com/show_bug.cgi?id=2111582 --- Comment #6 from cagney(a)fedoraproject.org --- This was extracted from Bug 2075736 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2111582

1 0

[Bug 2111582] virtqemud deadlocking
by bugzilla＠redhat.com 30 Jul '22

30 Jul '22

https://bugzilla.redhat.com/show_bug.cgi?id=2111582 Red Hat One Jira (issues.redhat.com) <redhat-one-jira(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Link ID| |Red Hat Issue Tracker | |SSSD-4910 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2111582

1 0

[Bug 2111582] virtqemud deadlocking
by bugzilla＠redhat.com 30 Jul '22

30 Jul '22

https://bugzilla.redhat.com/show_bug.cgi?id=2111582 Alexey Tikhonov <atikhono(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|sssd-maintainers(a)lists.fedo |atikhono(a)redhat.com |raproject.org | Status|NEW |ASSIGNED Whiteboard| |sync-to-jira review Keywords| |Triaged --- Comment #5 from Alexey Tikhonov <atikhono(a)redhat.com> --- (In reply to cagney from comment #4) > Probably the same It is. Fix already posted for review upstream: https://github.com/SSSD/sssd/pull/6289 -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2111582

1 0

[Bug 2111582] virtqemud deadlocking
by bugzilla＠redhat.com 30 Jul '22

30 Jul '22

1 0

[Bug 2107824] New: User logins doesn't use right kerberos tickets for cifs.upcall
by bugzilla＠redhat.com 28 Jul '22

28 Jul '22

https://bugzilla.redhat.com/show_bug.cgi?id=2107824 Bug ID: 2107824 Summary: User logins doesn't use right kerberos tickets for cifs.upcall Product: Fedora Version: 36 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Severity: low Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: kamarasu(a)aol.in QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, luk.claes(a)gmail.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Created attachment 1897647 --> https://bugzilla.redhat.com/attachment.cgi?id=1897647&action=edit ssd_gdm_cifs_autofs Description of problem: User logins doesn't use right kerberos tickets for cifs.upcall at first attempt, I've noticed this issue while login through GDM, I think it happens same with ssh as well. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Setup multiuser cifs automount map served from NAS 2. Install fedora 36 linux and perform realm join to SAMBA(AD role) 3. update /etc/dconf/profile/user with service-db:keyfile/user 4.Login through GDM Actual results: Jul 16 12:35:48 bullseye.int.lan kernel: FS-Cache: Loaded Jul 16 12:35:48 bullseye.int.lan kernel: Key type dns_resolver registered Jul 16 12:35:48 bullseye.int.lan kernel: Key type cifs.spnego registered Jul 16 12:35:48 bullseye.int.lan kernel: Key type cifs.idmap registered Jul 16 12:35:48 bullseye.int.lan kernel: CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount. Jul 16 12:35:48 bullseye.int.lan kernel: CIFS: Attempting to mount \\nas.int.lan\home Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=nas.int.lan;ip4=192.168.1.10;sec=krb5;uid=0x0;creduid=0x2a;user=gdm;pid=0x636 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: ver=2 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: host=nas.int.lan Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: ip=192.168.1.10 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: sec=1 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: uid=0 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: creduid=42 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: user=gdm Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: pid=1590 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: get_cachename_from_process_env: pathname=/proc/1590/environ Jul 16 12:35:48 bullseye.int.lan systemd[1]: Starting sssd-kcm.service - SSSD Kerberos Cache Manager... Jul 16 12:35:48 bullseye.int.lan systemd[1]: Started sssd-kcm.service - SSSD Kerberos Cache Manager. Jul 16 12:35:48 bullseye.int.lan audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd-kcm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jul 16 12:35:48 bullseye.int.lan sssd_kcm[1606]: Starting up Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: get_existing_cc: default ccache is KCM:42 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: get_tgt_time: unable to get principal Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: krb5_get_init_creds_keytab: -1765328378 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: Exit status 1 Jul 16 12:35:48 bullseye.int.lan kernel: CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed Jul 16 12:35:48 bullseye.int.lan kernel: CIFS: VFS: \\nas.int.lan Send error in SessSetup = -126 Jul 16 12:35:48 bullseye.int.lan kernel: CIFS: VFS: cifs_mount failed w/return code = -126 Expected results: cifs.spnego user suppose to be the one specified at login prompt and it should not be user=gdm Additional info: But few seconds later the mount cifs.upcall goes well as below Jul 16 12:36:55 bullseye.int.lan kernel: CIFS: Attempting to mount \\nas.int.lan\home Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2891]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=nas.int.lan;ip4=192.168.1.10;sec=krb5;uid=0x0;creduid=0x48d02750;user=kamarasu;pid=0xb48 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: ver=2 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: host=nas.int.lan Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: ip=192.168.1.10 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: sec=1 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: uid=0 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: creduid=1221601104 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: user=kamarasu Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: pid=2888 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2891]: get_cachename_from_process_env: pathname=/proc/2888/environ Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2891]: get_existing_cc: default ccache is KCM:1221601104:18284 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2891]: handle_krb5_mech: getting service ticket for nas.int.lan Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2891]: handle_krb5_mech: ob Please see the attachment ssd_gdm_cifs_autofs [root@bullseye cloud-user]# automount -m Mount point: /home/int.lan source(s): instance type(s): sss map: auto.home * | -fstype=cifs -rw -sec=krb5i -multiuser -user=$USER -cruid=$UID -cifsacl ://nas.int.lan/home [root@bullseye cloud-user]# cat /etc/sssd/sssd.conf [sssd] domains = int.lan config_file_version = 2 services = nss, pam, autofs [domain/int.lan] default_shell = /bin/bash krb5_store_password_if_offline = True cache_credentials = True krb5_realm = INT.LAN realmd_tags = manages-system joined-with-adcli id_provider = ad fallback_homedir = /home/%d/%u ad_domain = int.lan use_fully_qualified_names = False ldap_id_mapping = True #access_provider = ad autofs_provider = ad [root@bullseye cloud-user]# mount |grep nas //nas.int.lan/home on /home/int.lan/kamarasu type cifs (rw,relatime,vers=3.1.1,sec=krb5i,cruid=1221601104,cache=strict,multiuser,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.10,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,cifsacl,noperm,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,user=kamarasu) -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2107824

1 1

[Bug 2088481] New: selinux_child: Cannot beign SELinux transaction
by bugzilla＠redhat.com 05 Jul '22

05 Jul '22

https://bugzilla.redhat.com/show_bug.cgi?id=2088481 Bug ID: 2088481 Summary: selinux_child: Cannot beign SELinux transaction Product: Fedora Version: 34 Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: rcritten(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, luk.claes(a)gmail.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: Some logins fail under load due to contention over the SELinux transaction lock in libsemanage. I'm trying to gather scalability information on IPA. The test revolves around bringing up a number of client VMs, enrolling as IPA clients and running a forking client that does a PAM transaction with the login service. Each client has a set of unique users with non-expired passwords to authenticate with. No pre-loading of the cache is done. In this particular case I brought up 10 clients and ran the test tool do to 10 logins. All of these 100 logins happen more or less simultaneously (time is synced). 30 of the authentications failed due to the transaction locking. IPA should be able to handle 100 authentications without breaking a sweat and the server-side logs don't show any issues but it may be somewhat load related. If I re-run the test tool after the fact, even clearing the SSSD cache I can't reproduce the transaction failure. I wonder if a retry could be implemented. The selinux_child log contains the following. It is consistent across all the clients (log level 3): (2022-05-19 13:42:01): [selinux_child[11668]] [libsemanage] (0x0020): Could not get direct transaction lock at /var/lib/selinux/targeted/semanage.trans.LOCK. ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2022-05-19 13:41:56): [selinux_child[11668]] [main] (0x0400): selinux_child started. * (2022-05-19 13:41:56): [selinux_child[11668]] [main] (0x2000): Running with effective IDs: [0][0]. * (2022-05-19 13:41:56): [selinux_child[11668]] [main] (0x2000): Running with real IDs [0][0]. * (2022-05-19 13:41:56): [selinux_child[11668]] [main] (0x0400): context initialized * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): seuser length: 12 * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): seuser: unconfined_u * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): mls_range length: 14 * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023 * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): username length: 23 * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): username: user6client000.ipa.test * (2022-05-19 13:41:56): [selinux_child[11668]] [main] (0x0400): performing selinux operations * (2022-05-19 13:41:56): [selinux_child[11668]] [seuser_needs_update] (0x2000): sss_get_seuser: ret: 0 seuser: unconfined_u mls: s0-s0:c0.c1023 * (2022-05-19 13:41:56): [selinux_child[11668]] [sss_seuser_exists] (0x0400): seuser exists: no * (2022-05-19 13:41:56): [selinux_child[11668]] [seuser_needs_update] (0x0400): The SELinux user does need an update * (2022-05-19 13:42:01): [selinux_child[11668]] [libsemanage] (0x0020): Could not get direct transaction lock at /var/lib/selinux/targeted/semanage.trans.LOCK. ********************** BACKTRACE DUMP ENDS HERE ********************************* (2022-05-19 13:42:01): [selinux_child[11668]] [sss_set_seuser] (0x0020): Cannot begin SELinux transaction (2022-05-19 13:42:01): [selinux_child[11668]] [main] (0x0020): Cannot set SELinux login context. ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2022-05-19 13:42:01): [selinux_child[11668]] [sss_set_seuser] (0x0020): Cannot begin SELinux transaction * (2022-05-19 13:42:01): [selinux_child[11668]] [main] (0x0020): Cannot set SELinux login context. ********************** BACKTRACE DUMP ENDS HERE ********************************* (2022-05-19 13:42:01): [selinux_child[11668]] [main] (0x0020): selinux_child failed! (2022-05-19 13:42:01): [selinux_child[11671]] [libsemanage] (0x0020): Could not get direct transaction lock at /var/lib/selinux/targeted/semanage.trans.LOCK. ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2022-05-19 13:41:56): [selinux_child[11671]] [main] (0x0400): selinux_child started. * (2022-05-19 13:41:56): [selinux_child[11671]] [main] (0x2000): Running with effective IDs: [0][0]. * (2022-05-19 13:41:56): [selinux_child[11671]] [main] (0x2000): Running with real IDs [0][0]. * (2022-05-19 13:41:56): [selinux_child[11671]] [main] (0x0400): context initialized * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): seuser length: 12 * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): seuser: unconfined_u * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): mls_range length: 14 * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023 * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): username length: 23 * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): username: user1client000.ipa.test * (2022-05-19 13:41:56): [selinux_child[11671]] [main] (0x0400): performing selinux operations * (2022-05-19 13:41:56): [selinux_child[11671]] [seuser_needs_update] (0x2000): sss_get_seuser: ret: 0 seuser: unconfined_u mls: s0-s0:c0.c1023 * (2022-05-19 13:41:56): [selinux_child[11671]] [sss_seuser_exists] (0x0400): seuser exists: no * (2022-05-19 13:41:56): [selinux_child[11671]] [seuser_needs_update] (0x0400): The SELinux user does need an update * (2022-05-19 13:42:01): [selinux_child[11671]] [libsemanage] (0x0020): Could not get direct transaction lock at /var/lib/selinux/targeted/semanage.trans.LOCK. ********************** BACKTRACE DUMP ENDS HERE ********************************* (2022-05-19 13:42:01): [selinux_child[11671]] [sss_set_seuser] (0x0020): Cannot begin SELinux transaction (2022-05-19 13:42:01): [selinux_child[11671]] [main] (0x0020): Cannot set SELinux login context. ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2022-05-19 13:42:01): [selinux_child[11671]] [sss_set_seuser] (0x0020): Cannot begin SELinux transaction * (2022-05-19 13:42:01): [selinux_child[11671]] [main] (0x0020): Cannot set SELinux login context. ********************** BACKTRACE DUMP ENDS HERE ********************************* (2022-05-19 13:42:01): [selinux_child[11671]] [main] (0x0020): selinux_child failed! Version-Release number of selected component (if applicable): sssd-common-2.5.2-2.fc34 -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2088481

1 7

2024

2023

2022

2021

2020

Sssd-maintainers July 2022