February 2021 - Sssd-maintainers - Fedora mailing-lists

[Bug 1927907] New: Latest release sssd 2.4.1 hard requires Python 3
by bugzilla＠redhat.com 14 Mar '22

14 Mar '22

https://bugzilla.redhat.com/show_bug.cgi?id=1927907 Bug ID: 1927907 Summary: Latest release sssd 2.4.1 hard requires Python 3 Product: Fedora Version: 34 Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: jlebon(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, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: It seems since the 2.4.1 rebase (https://src.fedoraproject.org/rpms/sssd/c/9e5dd4b66572aeb348f3cc854ce7fca9f…), sssd now pulls in python3 because it changed python3-sssdconfig from a "Suggests" to a "Requires". In Fedora CoreOS, we're trying to avoid shipping Python entirely to encourage containerizing user workloads and to keep the OS minimal. In a rawhide and f34 build, this package was identified as pulling it back in. Would it be possible to make it a weak dep again? This would also be useful in other environments like containers and custom OS builds which value minimalism. We can help with that if there's agreement. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 10

[Bug 1886841] New: Pinpad card reader for login authentication yet you are asked also enter pin on pc keyboard
by bugzilla＠redhat.com 03 Feb '22

03 Feb '22

https://bugzilla.redhat.com/show_bug.cgi?id=1886841 Bug ID: 1886841 Summary: Pinpad card reader for login authentication yet you are asked also enter pin on pc keyboard Product: Fedora Version: 32 Hardware: x86_64 URL: https://lists.fedoraproject.org/archives/list/freeipa- users(a)lists.fedorahosted.org/thread/FLLIA5RLHT3MO4NI2F 3MJNMBBNGGZA4Z/ OS: Linux Status: NEW Component: sssd Severity: high Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: peter(a)unix-edu.se QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Build Identifier: Hello Folks! We are working on getting smart card authentication working using pinpad card readers for improved security. To do this we use: FreeIPA Server is running on Fedora 32 with latest updates. FreeIPA Clients is Fedora 32 Workstation installed on pc with latest updates with connected usb card reader. The card reader is Gemalto CT700 with pinpad, we use several user individual SmartCard HSM 4K with FreeIPA signed certificates on them. FreeIPA Clients run OpenSC and are configured to use smartcard certificate based authentication, setup per Smartare HSM best practice. Further clients are using SSSD and not PAM_PKCS#11. All working great using smartcard for authentication, as long not enabling the pinpad in opensc. If doing so we are prompted for the PIN not only in the pinpad reader but also GDM prompts you to enter PIN on keyboard. Expected result is to be logged in directly after entering correct PIN code on pinpad reader, not being prompted by GDM to enter PIN on keyboard as well. If enabling pinpad in opensc, login gets a bit odd: 1. Fedora 32 Workstation GDM menu prompts a few users that can login. 2. Smartcard is inserted in reader. 3. GDM blanks out the screen and smartcard reader prompts to enter PIN in its lcd display. 4. Entering pin on smartcard reader followed by pressing ok button on smartcard reader at getting result Pin OK in reader display. 5. GDM now prompts for entering PIN on keyboard, this is unexpected, instead of directly being logged in to the window manager, here Gnome (or xfce, whatever window manager you selected to use). 6. You have to enter the PIN now on keyboard, followed by hitting enter. 7. Once again smartcard reader now prompts for PIN in its lcd display. 8. Entering PIN on the smartcard pinpad reader followed by pressing pinpad ok button. 9. You are now logged in, and all is normal. If ripping out the smartcard from reader the screen locks, as expected. Sometimes, but not always, you are logged in to window manager directly after step 5. What could this be, anyone who have seen this before or know how to set it up ? Reproducible: Always Steps to Reproduce: 1. Install and setup FreeIPA server and client on Fedora32 latest updates to use smartcard authentication for login. Work on IPA Server: ------------------- Install Fedora 32 server minimal installation all excluded, update to latest version (dnf update -y), set hostname, enter server hostname (ipaserver.mydomain.com) and ip in /etc/hosts, enable and start chrony, reboot. (As root user) dnf install ipa-server bind-dyndb-ldap ipa-server-dns -y for SERVICES in ntp http https ldap ldaps kerberos kpasswd dns; do firewall-cmd --permanent --add-service=$SERVICES; done ipa-server-install --setup-dns . . . Add one secondary DNS in /etc/NetworkManager/conf.d/zzz-ipa.conf klist kinit admin authselect select sssd with-sudo with-mkhomedir ipa user-add user3 --first=user3 --last=test --email=user3(a)mydomain.com --shell=/bin/bash --password id user3 ipa user-find user3 ssh user3(a)ipaserver.mydomain.com (change password) reboot (As root user) klist kinit admin ipa-advise config-server-for-smart-card-auth > config-server-for-smart-card-auth.sh chmod u+x config-server-for-smart-card-auth.sh ./config-server-for-smart-card-auth.sh /etc/ipa/ca.crt . . reboot ipa-advise config-client-for-smart-card-auth > /tmp/config-client-for-smart-card-auth.sh chmod a+r /tmp/config-client-for-smart-card-auth.sh Work on Fedora 32 workstation: ------------------------------ Install Fedora 32 Workstation from live dvd to PC, update to latest version (dnf update -y), set hostname, enter server hostname (workstation.mydomain.com) and ip in /etc/hosts, enable and start chrony. change/add to /etc/sysconfig/network-scripts/reboot, so IPA server becomes primary DNS for the Fedora 32 Workstation: PEERDNS=no DNS1=<ipa server ip address> DNS2=<second dns server> SEARCH=mydomain.com DOMAIN=mydomain.com Then reboot Login and check that DNS is working. (as root user) dnf install freeipa-client.x86_64 -y ipa-client-install --mkhomedir id user3 reboot Connect gemalto CT700 card reader to pc/Fedora Workstation. lsusb dnf install opensc ccid pcsc-tools -y systemctl enable pcscd systemctl start pcscd scp user3@ipaserver:/tmp/config-client-for-smart-card-auth.sh . chmod +x config-client-for-smart-card-auth.sh ./config-client-for-smart-card-auth.sh /etc/ipa/ca.crt . . . In /etc/opensc.conf enable pinpad by uncommenting enable_pinpad = true; Ensure pam_cert_auth is true in sssd.conf: grep ^pam_cert_auth /etc/sssd/sssd.conf pam_cert_auth = True authselect select sssd with-mkhomedir with-sudo with-smartcard with-smartcard-lock-on-removal --force authselect current reboot 2. Prepare smartcard-hsm with user3 certificate using (as root user) kinit admin Insert smartcard-hsm in gemalto ct700 card reader! pcsc_scan Using reader plug'n play mechanism Scanning present readers... 0: Gemalto Ezio Shield (I<some number>) 00 00 Wed Sep 23 14:12:27 2020 Reader 0: Gemalto Ezio Shield (I<some number>) 00 00 . . . Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): <some hex number> Smartcard-HSM http://www.cardcontact.de/products/sc-hsm.html pensc-tool --list-readers # Detected readers (pcsc) Nr. Card Features Name 0 Yes PIN pad Gemalto Ezio Shield (I<some number>) 00 00 pkcs11-tool --list-slots Available slots: Slot 0 (0x0): Gemalto Ezio Shield (I<some number>) 00 00 token label : UserPIN (SmartCard-HSM) token manufacturer : www.CardContact.de token model : PKCS#15 emulated token flags : login required, PIN pad present, rng, token initialized, PIN initialized hardware version : 24.13 firmware version : 2.5 serial num : DECM<some number> pin min/max : 6/15 sc-hsm-tool --create-dkek-share dkek-share-1.pbe . . . sc-hsm-tool --initialize --so-pin <long pincode> --pin <pincode> --dkek-shares 1 sc-hsm-tool . . . DKEK shares : 1 DKEK import pending, 1 share(s) still missing sc-hsm-tool --import-dkek-share dkek-share-1.pbe . . . Enter password to decrypt DKEK share : <pincode> sc-hsm-tool . . . DKEK shares : 1 DKEK key check value : <some hex code> # generate keypair pkcs11-tool --module opensc-pkcs11.so --login --pin <pincode> --keypairgen --key-type rsa:2048 --id 10 --label "HSM RSA Key user3" pkcs11-tool --list-objects . . . pkcs11-tool --test --login --pin <pincode> . . . # Backup DKEK sc-hsm-tool --wrap-key wrap-key-1.bin --key-reference 1 --pin <pincode> # Extract card public key for slot 10 pkcs15-tool --read-public-key 10 > user3.pub # Prepping for and Create CSR to sign by IPA for user3 # Create a file hsm.conf with the content below cat hsm.conf # PKCS11 engine config openssl_conf = openssl_def [openssl_def] engines = engine_section [req] distinguished_name = req_distinguished_name [req_distinguished_name] # empty. [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 PIN = init = 0 # Test that hsm.conf is working, and find pkcs11 engine OPENSSL_CONF=./hsm.conf openssl engine (rdrand) Intel RDRAND engine (dynamic) Dynamic engine loading support (pkcs11) pkcs11 engine # Create CSR to sign by IPA for user3 OPENSSL_CONF=./hsm.conf openssl req -engine pkcs11 -keyform engine -new -key 10 -sha256 -out user3.csr -subj "/CN=user3" Login to IPA server using the web interface https://ipaserver.mydomain.com (this can be performed from command line as well, but we did use the web interface to IPA) user user3 Actions -> new certificate select profile IECuserRoles copy "user3.csr" from above and paste it in and click "issue" (IPA now sign the CSR) To retrieve the signed certificate for user3: user user3 by Certificates click Actions -> Download and save as. (it downloads as cert.pem) Copy the downloaded cerificate (cert.pem) to host with card reader (Fedora 32 Workstation) Rename it: mv cert.pem user3.pem # convert to der format: openssl x509 -in user3.pem -out user3.der -outform der # write it to the card in slot 10 pkcs11-tool --module opensc-pkcs11.so --login --pin <pincode> --write-object user36.der --type cert --id 10 # check that it is there: pkcs11-tool --list-objects Using slot 0 with a present token (0x0) Certificate Object; type = X.509 cert label: Certificate subject: DN: O=MYDOMAIN.COM, CN=user3 ID: 10 Public Key Object; RSA 2048 bits label: Certificate ID: 10 Usage: encrypt, verify Smartcard should now be ready for use with IPA. 3. Now try login to workstation.mydomain.com using GDM using the smartcard issued for user3 Note! user3 password must not have been expired, it should be fixed by the initial login test above. As per details above: 1. Fedora 32 Workstation GDM menu prompts a few users that can login. 2. Smartcard is inserted in reader. 3. GDM blanks out the screen and smartcard reader prompts to enter PIN in its lcd display. 4. Entering pin on smartcard reader followed by pressing ok button on smartcard reader at getting result Pin OK in reader display. 5. GDM now prompts for entering PIN on keyboard, this is unexpected, instead of directly being logged in to the window manager, here Gnome (or xfce, whatever window manager you selected to use). 6. You have to enter the PIN now on keyboard, followed by hitting enter. 7. Once again smartcard reader now prompts for PIN in its lcd display. 8. Entering PIN on the smartcard pinpad reader followed by pressing pinpad ok button. 9. You are now logged in, and all is normal. If ripping out the smartcard from reader the screen locks, as expected. Sometimes, but not always, you are logged in to window manager directly after step 5. Actual Results: You are asked to enter PIN using pinpad on card reader followed by enter PIN using the keyboard, then you are logged in. Sometimes you need to enter PIN on pinpad once more after entering PIN using the keyboard. Expected Results: Directly after entering correct PIN using pinpad on card reader you should be logged in. Versions: Fedora32 with latest updates per Oct 9 2020. freeipa-server-4.8.10-5.fc32.x86_64 freeipa-client-4.8.10-5.fc32.x86_64 sssd-client-2.3.1-2.fc32.x86_64 opensc-0.20.0-6.fc32.x86_64 pcsc-lite-libs-1.9.0-1.fc32.x86_64 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 6

[Bug 1857104] New: Using FreeIPA breaks IPv4/IPv6 flags for SSH
by bugzilla＠redhat.com 03 Feb '22

03 Feb '22

https://bugzilla.redhat.com/show_bug.cgi?id=1857104 Bug ID: 1857104 Summary: Using FreeIPA breaks IPv4/IPv6 flags for SSH Product: Fedora Version: 32 Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: ossman(a)cendio.se QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: If a client is configured using ipa-client-install then the -4 and -6 flags stop working for ssh. Version-Release number of selected component (if applicable): Doesn't matter. Seen on RHEL 6 through 8, and on current Fedora. How reproducible: 100% Steps to Reproduce: 1. ipa-client-install 2. ssh -4 host.example.com Actual results: Connected via IPv6 Expected results: Connected via IPv4 Additional info: The bug is that sss_ssh_knownhostsproxy is configured on the client and that command doesn't respect the flags given to ssh. The issue affects all hosts, not just those part of the same FreeIPA domain. A practical effect of this is that connections get rejected or misbehave because of IP based rules in place for this connection. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 17

[Bug 1886816] New: [abrt] sssd-common: sss_mmap_cache_pw_store(): sssd_nss killed by SIGBUS
by bugzilla＠redhat.com 30 Nov '21

30 Nov '21

https://bugzilla.redhat.com/show_bug.cgi?id=1886816 Bug ID: 1886816 Summary: [abrt] sssd-common: sss_mmap_cache_pw_store(): sssd_nss killed by SIGBUS Product: Fedora Version: 33 Hardware: x86_64 Status: NEW Whiteboard: abrt_hash:cd13c552f85949e67c1f8b9066dc4393eee0ce85;VAR IANT_ID=workstation; Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: kparal(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, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Version-Release number of selected component: sssd-common-2.3.1-4.fc33 Additional info: reporter: libreport-2.14.0 backtrace_rating: 4 cgroup: 0::/system.slice/sssd.service cmdline: /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files crash_function: sss_mmap_cache_pw_store executable: /usr/libexec/sssd/sssd_nss journald_cursor: s=b2e7c0583c004ae8bd317a4440255076;i=2ee4a7;b=7c261537394f4d169971a59cd1761dfe;m=55626889;t=5b13c2149d0cf;x=8fed0b78d48ecd6c kernel: 5.8.14-300.fc33.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (10 frames) #0 sss_mmap_cache_pw_store at src/responder/nss/nsssrv_mmap_cache.c:769 #1 nss_protocol_fill_pwent at src/responder/nss/nss_protocol_pwent.c:308 #2 nss_protocol_reply at src/responder/nss/nss_protocol.c:91 #3 nss_getby_done at src/responder/nss/nss_cmd.c:626 #4 tevent_common_invoke_immediate_handler at ../../tevent_immediate.c:166 #5 tevent_common_loop_immediate at ../../tevent_immediate.c:203 #6 epoll_event_loop_once at ../../tevent_epoll.c:917 #7 std_event_loop_once at ../../tevent_standard.c:110 #8 _tevent_loop_once at ../../tevent.c:772 #9 tevent_common_loop_wait at ../../tevent.c:895 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 13

[Bug 1853261] New: sssd fails to start on read-only filesystem
by bugzilla＠redhat.com 30 Nov '21

30 Nov '21

https://bugzilla.redhat.com/show_bug.cgi?id=1853261 Bug ID: 1853261 Summary: sssd fails to start on read-only filesystem Product: Fedora Version: rawhide Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: zbyszek(a)in.waw.pl QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: sssd refuses to start when /var/log is read-only. It is obviously a problem when trying to recover from a file system issue. Since logging is non-essential, sssd should just continue. At most is should emit a warning. $ touch /var/tmp/foo touch: cannot touch '/var/tmp/foo': Read-only file system $ sudo systemctl start sssd.service Job for sssd.service failed because the control process exited with error code. See "systemctl status sssd.service" and "journalctl -xe" for details. [fedora@workstation-uefi ~]$ Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02 11:16:46 CEST): sssd[900]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only file system] Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02 11:16:47 CEST): sssd[903]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only file system] Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02 11:16:47 CEST): sssd[905]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only file system] Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02 11:16:47 CEST): sssd[906]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only file system] Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02 11:16:47 CEST): sssd[907]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only file system] We see multiple issues here: - the main one is that sssd should not fail to start as described above - but also, why is sssd not just logging to the journal? Why is it spamming with broadcast messages? If sssd would just log to the journal like any modern service, all those problems would be avoided. Version-Release number of selected component (if applicable): sssd-2.3.0-2.fc33.x86_64 How reproducible: Deterministic Steps to Reproduce: 1. Make /var/log read-only, either by not remounting the filesystems rw, or by using udev.blockdev-read-only with systemd-246+ 2. Try to start sssd -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 18

[Bug 1868696] New: sssd_kcm loops on NFS server occasionally after an NFSv4.0 mount using Kerberos
by bugzilla＠redhat.com 25 May '21

25 May '21

https://bugzilla.redhat.com/show_bug.cgi?id=1868696 Bug ID: 1868696 Summary: sssd_kcm loops on NFS server occasionally after an NFSv4.0 mount using Kerberos Product: Fedora Version: 32 Hardware: All OS: Linux Status: NEW Component: sssd Severity: high Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: chuck.lever(a)oracle.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, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: Multi-homed Fedora 32 NFS client and server, both with keytabs. Sometimes after performing an NFSv4.0 mount, the sssd_kcm daemon on the server runs at 100% and fills up the sssd_kcm.log file (and eventually, the root partition). (2020-08-10 15:03:04:680265): [kcm] [kcm_input_parse] (0x1000): Received message with length 0 (2020-08-10 15:03:04:680284): [kcm] [kcm_input_parse] (0x0020): Illegal zero-length message (2020-08-10 15:03:04:680302): [kcm] [kcm_recv] (0x0010): Failed to parse data (74, Bad message), aborting client (2020-08-10 15:03:04:680319): [kcm] [kcm_reply_error] (0x0040): KCM operation returs failure [74]: Bad message (2020-08-10 15:03:04:680353): [kcm] [kcm_failbuf_construct] (0x1000): Sent reply with error -1765328188 Version-Release number of selected component (if applicable): sssd-kcm-2.3.1-2.fc32.x86_64 How reproducible: Happens every second or third mount operation. Steps to Reproduce: 1. Set up NFS client and server with keytabs 2. Repeat: "mount -o vers=4.0,sec=sys" / do some operations / umount 3. Watch the server with "top" Actual results: Sometimes sssd_kcm goes to 100% of a CPU and must be killed. Expected results: No looping. Additional info: The NFSv4.0 backchannel, in this case, is secured with GSS krb5i. It appears that gssd on the server is accessing the Kerberos ticket cache while setting up the backchannel, and sometimes this triggers the kcm loop. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 3

[Bug 1884912] New: [abrt] sssd-common: __strcmp_avx2(): sssd_be killed by SIGSEGV
by bugzilla＠redhat.com 08 Apr '21

08 Apr '21

https://bugzilla.redhat.com/show_bug.cgi?id=1884912 Bug ID: 1884912 Summary: [abrt] sssd-common: __strcmp_avx2(): sssd_be killed by SIGSEGV Product: Fedora Version: 32 Hardware: x86_64 Status: NEW Whiteboard: abrt_hash:a07038fd78acc47fd66b266203cafebd50509e00;VAR IANT_ID=workstation; Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: rbrattai(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, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com Target Milestone: --- Group: fedora_contrib_private Classification: Fedora Description of problem: Always happens when the Kerberos tickets expire after letting the system sit overnight. Log in to Redhat krbtgt/REDHAT.COM(a)REDHAT.COM let the system sit overnight, or until ticket expires try to login via gdm or vt login fails Version-Release number of selected component: sssd-common-2.3.1-2.fc32 Additional info: reporter: libreport-2.13.1 backtrace_rating: 4 cgroup: 0::/system.slice/sssd.service cmdline: /usr/libexec/sssd/sssd_be --domain redhat.com --uid 0 --gid 0 --logger=files crash_function: __strcmp_avx2 executable: /usr/libexec/sssd/sssd_be journald_cursor: s=a7dff00ea3904bcf94e9c47f3af11249;i=99168;b=d69fa027bac74e0c82bae802fce15dc2;m=8e9b12f6b4;t=5b0c43dd4cdcb;x=5af4a1ece75efc5a kernel: 5.7.17-200.fc32.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (10 frames) #0 __strcmp_avx2 at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:101 #1 be_resolve_server_process at src/providers/data_provider_fo.c:671 #2 be_resolve_server_done at src/providers/data_provider_fo.c:555 #3 fo_resolve_service_server at src/providers/fail_over.c:1165 #4 _tevent_req_error at ../../tevent_req.c:211 #5 resolve_srv_done at src/providers/fail_over.c:1466 #6 fo_discover_srv_done at src/providers/fail_over_srv.c:141 #7 resolv_discover_srv_done at src/resolv/async_resolv_utils.c:302 #8 resolv_getsrv_done at src/resolv/async_resolv.c:1762 #9 qcallback at /usr/src/debug/c-ares-1.15.0-5.fc32.x86_64/ares_query.c:183 Potential duplicate: bug 1773488 -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 1910169] New: sssd-kcm causing periodic auth failures after 2.4.0-2
by bugzilla＠redhat.com 05 Mar '21

05 Mar '21

https://bugzilla.redhat.com/show_bug.cgi?id=1910169 Bug ID: 1910169 Summary: sssd-kcm causing periodic auth failures after 2.4.0-2 Product: Fedora Version: 33 Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: rwf(a)loonybin.net QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora sssd-kcm is causing periodic auth failures on builds newer than 2.4.0-2, presumably due to an issue introduced with the (surprising number of) patches applied in 2.4.0-3. (Incidentally, CPU usage by the process has gotten substantially worse in these versions, as well.) This manifests as all plaintext auth failing on Fedora 33 systems running sssd 2.4.0-4, joined to a FreeIPA domain and authenticating domain users, which will emit errors like the following examples for the lifetime of the sssd-kcm process that incurred the problem: Dec 22 17:59:11 fedora33 systemd[1]: Starting SSSD Kerberos Cache Manager... Dec 22 17:59:11 fedora33 systemd[1]: Started SSSD Kerberos Cache Manager. Dec 22 17:59:11 fedora33 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' Dec 22 17:59:11 fedora33 kcm[10556]: Starting up Dec 22 17:59:11 fedora33 krb5_child[10554][10554]: Generic error (see e-text) Dec 22 17:59:11 fedora33 krb5_child[10554][10554]: Generic error (see e-text) Dec 22 17:59:11 fedora33 auth[10552]: pam_sss(dovecot:auth): authentication failure; logname= uid=97 euid=97 tty=dovecot ruser=rob rhost=2001:db8::1 user=rob Dec 22 17:59:11 fedora33 auth[10552]: pam_sss(dovecot:auth): received for user rob: 4 (System error) Dec 22 17:59:19 fedora33 krb5_child[10559][10559]: Generic error (see e-text) Dec 22 17:59:19 fedora33 krb5_child[10559][10559]: Generic error (see e-text) Dec 22 17:59:19 fedora33 auth[10552]: pam_sss(dovecot:auth): authentication failure; logname= uid=97 euid=97 tty=dovecot ruser=rob rhost=2001:db8::1 user=rob Dec 22 17:59:19 fedora33 auth[10552]: pam_sss(dovecot:auth): received for user rob: 4 (System error) Dec 22 17:59:29 fedora33 krb5_child[10562][10562]: Generic error (see e-text) Dec 22 17:59:29 fedora33 krb5_child[10562][10562]: Generic error (see e-text) Dec 22 17:59:29 fedora33 auth[10552]: pam_sss(dovecot:auth): authentication failure; logname= uid=97 euid=97 tty=dovecot ruser=rob rhost=2001:db8::1 user=rob Dec 22 17:59:29 fedora33 auth[10552]: pam_sss(dovecot:auth): received for user rob: 4 (System error) Nothing else is logged anywhere. Also affected are sudo and the like, but not any authentication using Kerberos tickets. Relatively short-lived workarounds include waiting it out (sssd-kcm process exits, next auth attempt spawns a new one and succeeds) or rebooting the host. klist as affected users during these events reports no KCM cache for the respective UID available, and kinit also usually fails with the same 'Generic error' text until the sssd-kcm process goes away. Downgrading sssd* packages to 2.4.0-2 restores correct behavior. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 4

[Bug 1676961] sss_cache ignores effective uid
by bugzilla＠redhat.com 25 Feb '21

25 Feb '21

https://bugzilla.redhat.com/show_bug.cgi?id=1676961 --- Comment #8 from Sumit Bose <sbose(a)redhat.com> --- Hi, thanks for explaining your use case. I would recommend to use auditd do record which user is doing what with sudo, see e.g. https://sudoedit.com/log-sudo-with-auditd/. As an example. If I set sudo auditctl -a exit,always -F arch=b64 -F euid=0 -F path=/usr/sbin/sss_cache -S execve -k sudo_audit and a user with UID 1000 then calls date ; sudo sss_cache -E Thu Feb 25 14:59:56 UTC 2021 then the administrator can later call sudo ausearch -ua vagrant -k sudo_audit -x /usr/sbin/sss_cache time->Thu Feb 25 14:59:56 2021 type=PROCTITLE msg=audit(1614265196.620:5737): proctitle=7373735F6361636865002D45 type=PATH msg=audit(1614265196.620:5737): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=153852 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(1614265196.620:5737): item=0 name="/sbin/sss_cache" inode=606020 dev=fd:01 mode=0104555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(1614265196.620:5737): cwd="/home/vagrant" type=EXECVE msg=audit(1614265196.620:5737): argc=2 a0="sss_cache" a1="-E" type=SYSCALL msg=audit(1614265196.620:5737): arch=c000003e syscall=59 success=yes exit=0 a0=561aea8a88b8 a1=561aea8b0178 a2=561aea8c7160 a3=1 items=2 ppid=59080 pid=59082 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sss_cache" exe="/usr/sbin/sss_cache" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sudo_audit" So you get full path of the command with options, execution time and 'auid=1000' If you prefer to do this manually in scripts you can check /proc/self/loginuid, e.g. sudo cat /proc/self/loginuid 1000 I hope one of this will work for you. bye, Sumit -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1676961] sss_cache ignores effective uid
by bugzilla＠redhat.com 23 Feb '21

23 Feb '21

https://bugzilla.redhat.com/show_bug.cgi?id=1676961 --- Comment #7 from Thomas Walker Lynch <thomas.walker.lynch(a)gmail.com> --- to be more clear, to write programs to help users do system tasks, where the knowledge of who the user is is required. That is why there is an inherited uid in addition to the effective uid. There are workarounds, such as passing identifying information through the environment, but those work arounds are not secure, because, unlike the inherited uid, the environment may be spoofed. .. that is why the inherited uid and such identification is handled by the OS instead of the application layer, but sudo is currently defeating this mechanism. And thus, indeed, I do believe it is a bug. -- You are receiving this mail because: You are the assignee for the bug.

1 0

2024

2023

2022

2021

2020

Sssd-maintainers February 2021