[Bug 2088481] New: selinux_child: Cannot beign SELinux transaction
by bugzilla＠redhat.com
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 month, 1 week
[Bug 1965818] New: sssd - failing on "dotted"languages (Example turkish language)
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1965818
Bug ID: 1965818
Summary: sssd - failing on "dotted"languages (Example turkish
language)
Product: Fedora
Version: 34
Hardware: x86_64
OS: Linux
Status: NEW
Component: sssd
Severity: high
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: thunderbirdtr(a)fedoraproject.org
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:
Hello,
SSSD Service isn't starting If we use dotted language in our system. For
example, adding "LANG=tr_TR" into "/etc/sysconfig/sssd" makes sssd fails on
start. If anyone install Fedora with "turkish" or other dotted language in
their pc/laptop, that makes sssd fails on start.
After I made little bit research, I notice this issue has been addressed
multiple times around RHEL[0] and samba[1] and github[2] as well. So for that
reason at least can we add "english" locale setting into rpm spec with
"language" check as a workaround has been suggest in github link.That is at
least gives us "working" package in dotted languge, and If anyone wants change
setting, they can change it. At least for normal users, we can have working
sssd service and not complain about fails all the times. I know this isn't the
cleanest solution (proper solution is patching libldb package which causing
this issue, but at least we can have a "quick&dirty" solution avoid on new
installs.
Thank you.
[0] : https://bugzilla.redhat.com/show_bug.cgi?id=1743531
[1] : https://lists.samba.org/archive/samba-technical/2019-December/134659.html
[2] : https://github.com/SSSD/sssd/issues/5285
Version-Release number of selected component (if applicable):
sssd-2.5.0-2.fc34.x86_64
libldb-2.3.0-2.fc34.x86_64
How reproducible:
Steps to Reproduce:
1. Install Fedora or change language into dotted or change "LANG" env into
dotted langauge
2. reset sssd counter
3. start sssd
Actual results:
sssd fails
Expected results:
sssd should start clean in default config.
Additional info:
SSSD Systemctl errors
systemd[1]: Starting System Security Services Daemon...
sssd[760632]: Starting up
systemd[1]: sssd.service: Main process exited,
code=exited, status=4/NOPERMISSION
systemd[1]: sssd.service: Failed with result
'exit-code'.
systemd[1]: Failed to start System Security Services
Daemon.
audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
systemd[1]: sssd.service: Scheduled restart job,
restart counter is at 1.
systemd[1]: Stopped System Security Services Daemon.
audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
systemd[1]: Starting System Security Services Daemon...
sssd[760633]: Starting up
systemd[1]: sssd.service: Main process exited,
code=exited, status=4/NOPERMISSION
systemd[1]: sssd.service: Failed with result
'exit-code'.
systemd[1]: Failed to start System Security Services
Daemon.
audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
systemd[1]: sssd.service: Scheduled restart job,
restart counter is at 2.
audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
systemd[1]: Stopped System Security Services Daemon.
systemd[1]: Starting System Security Services Daemon...
sssd[760636]: Starting up
systemd[1]: sssd.service: Main process exited,
code=exited, status=4/NOPERMISSION
systemd[1]: sssd.service: Failed with result
'exit-code'.
systemd[1]: Failed to start System Security Services
Daemon.
audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
systemd[1]: sssd.service: Scheduled restart job,
restart counter is at 3.
systemd[1]: Stopped System Security Services Daemon.
audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
systemd[1]: Starting System Security Services Daemon...
sssd[760637]: Starting up
systemd[1]: sssd.service: Main process exited,
code=exited, status=4/NOPERMISSION
systemd[1]: sssd.service: Failed with result
'exit-code'.
systemd[1]: Failed to start System Security Services
Daemon.
audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
systemd[1]: sssd.service: Scheduled restart job,
restart counter is at 4.
systemd[1]: Stopped System Security Services Daemon.
audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
systemd[1]: Starting System Security Services Daemon...
sssd[760639]: Starting up
systemd[1]: sssd.service: Main process exited,
code=exited, status=4/NOPERMISSION
systemd[1]: sssd.service: Failed with result
'exit-code'.
systemd[1]: Failed to start System Security Services
Daemon.
audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
-----------
/var/log/sssd/sssd.log (last error with LANG setting is tr_TR (LANG=tr_TR) )
-----------
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING
BACKTRACE:
* (2021-05-30 15:46:52): [sssd] [check_file] (0x0400): lstat for
[/run/sssd.pid] failed: [2][No such file or directory].
* (2021-05-30 15:46:52): [sssd] [check_file] (0x0400): lstat for
[/var/run/nscd/socket] failed: [2][No such file or directory].
* (2021-05-30 15:46:52): [sssd] [ldb] (0x0400): server_sort:Unable to
register control with rootdse!
* (2021-05-30 15:46:52): [sssd] [sss_ini_open] (0x0400): No
/etc/sssd/sssd.conf.
* (2021-05-30 15:46:52): [sssd] [sss_ini_read_sssd_conf] (0x0100): File
/etc/sssd/sssd.conf does not exist.
* (2021-05-30 15:46:52): [sssd] [confdb_ldif_from_ini_file] (0x0100): Value
of config_file_version option not found. Assumed to be version 2.
* (2021-05-30 15:46:52): [sssd] [sss_confdb_create_ldif] (0x0400):
Processing config section [sssd]
* (2021-05-30 15:46:52): [sssd] [sss_confdb_create_ldif] (0x0400):
Processing attribute [services]
* (2021-05-30 15:46:52): [sssd] [sss_confdb_create_ldif] (0x4000):
services:
nss
* (2021-05-30 15:46:52): [sssd] [sss_confdb_create_ldif] (0x4000): Section
dn
dn: cn=sssd,cn=config
cn: sssd
services: nss
* (2021-05-30 15:46:52): [sssd] [confdb_init_db] (0x0100): LDIF file to
import:
dn: cn=config
version: 2
dn: cn=sssd,cn=config
cn: sssd
services: nss
* (2021-05-30 15:46:52): [sssd] [add_implicit_services] (0x0040): No
domains
configured!
* (2021-05-30 15:46:52): [sssd] [get_monitor_config] (0x0040): Failed to
add
implicit configured services. Some functionality might be missing
* (2021-05-30 15:46:53): [sssd] [confdb_expand_app_domains] (0x2000):
implicit_files is not an app domain
* (2021-05-30 15:46:53): [sssd] [confdb_get_domain_internal] (0x0400): No
enumeration for [implicit_files]!
* (2021-05-30 15:46:53): [sssd] [confdb_get_domain_internal] (0x0400):
Please note that when enumeration is disabled `getent passwd` does not return
all users by design. See sssd.conf man page for more detailed information
* (2021-05-30 15:46:53): [sssd] [confdb_get_domain_internal] (0x1000):
pwd_expiration_warning is -1
* (2021-05-30 15:46:53): [sssd] [server_setup] (0x0080): Failed setting
process group: Operation not permitted[1]. We might leak processes in case of
failure
* (2021-05-30 15:46:53): [sssd] [become_user] (0x0200): Trying to become
user [0][0].
* (2021-05-30 15:46:53): [sssd] [become_user] (0x0200): Already user [0].
* (2021-05-30 15:46:53): [sssd] [ldb] (0x0400): server_sort:Unable to
register control with rootdse!
* (2021-05-30 15:46:53): [sssd] [server_setup] (0x0400): CONFDB:
/var/lib/sss/db/config.ldb
* (2021-05-30 15:46:53): [sssd] [confdb_get_enabled_domain_list] (0x0040):
Failed to get [domains] from [sssd], error [2] (Böyle bir dosya ya da dizin
yok)
********************** BACKTRACE DUMP ENDS HERE
*********************************
(2021-05-30 15:46:53): [sssd] [main] (0x0010): No domains configured.
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING
BACKTRACE:
* (2021-05-30 15:46:53): [sssd] [confdb_get_domains] (0x0080): No domains
configured, fatal error!
* (2021-05-30 15:46:53): [sssd] [main] (0x0010): No domains configured.
********************** BACKTRACE DUMP ENDS HERE
*********************************
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
1 month, 3 weeks
[Bug 2094685] New: Default of 'pac_check' is too strict
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2094685
Bug ID: 2094685
Summary: Default of 'pac_check' is too strict
Product: Fedora
Version: 36
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: sbose(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:
Default of 'pac_check' is too strict, it currently requires that a PAC is
present when using ipa or ad provider. While it would work with the AD provider
in most cases for ipa there is a fair chance that the PAC will not be
available.
If authentication fails and there are messages like "[validate_tgt] ... PAC
check failed for principal ..." you are most probably affected by this issue.
As a work-around set
pac_check = check_upn, check_upn_dns_info_ex
in the [pac] section of sssd.conf.
--
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=2094685
1 month, 4 weeks
[Bug 2095356] New: Password auth against FreeIPA server no longer works after update to Fedora 36
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2095356
Bug ID: 2095356
Summary: Password auth against FreeIPA server no longer works
after update to Fedora 36
Product: Fedora
Version: 36
Status: NEW
Component: sssd
Severity: high
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: boroske(a)ida.ing.tu-bs.de
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 1888388
--> https://bugzilla.redhat.com/attachment.cgi?id=1888388&action=edit
krb5_child.log of attempt to login using password auth
I recently upgraded a fedora 35 system to fedora 36.
After the upgrade, using any type of password auth against the freeipa server
no longer works (ssh, su, sudo), only local user logins or ssh public key
login.
The problem seems to have to do with the new sssd package.
I can see an error message in dmesg:
[ 743.242553] sssd_be[848]: segfault at 18 ip 00007f9bd8b5559c sp
00007ffd21604bc0 error 4 in libc.so.6[7f9bd8aeb000+173000]
I also enabled debug logging in sssd.conf and got error messages in
/var/log/sssd/krb5_child.log
excerpt (see attachment for full log of login attempt):
[...]
(2022-06-09 14:51:22): [krb5_child[1808]] [validate_tgt] (0x0400): [RID#18] TGT
verified using key for [host/zeus.net.ida(a)NET.IDA].
(2022-06-09 14:51:22): [krb5_child[1808]] [sss_child_krb5_trace_cb] (0x4000):
[RID#18] [1808] 1654779082.856019: Retrieving thomasb(a)NET.IDA ->
host/zeus.net.ida(a)NET.IDA from MEMORY:rd_req2 with result: 0/Success
(2022-06-09 14:51:22): [krb5_child[1808]] [sss_extract_pac] (0x0040): [RID#18]
No PAC authdata available.
(2022-06-09 14:51:22): [krb5_child[1808]] [validate_tgt] (0x0020): [RID#18] PAC
check failed for principal [thomasb(a)NET.IDA].
(2022-06-09 14:51:22): [krb5_child[1808]] [sss_child_krb5_trace_cb] (0x4000):
[RID#18] [1808] 1654779082.856020: Destroying ccache MEMORY:rd_req2
(2022-06-09 14:51:22): [krb5_child[1808]] [get_and_save_tgt] (0x0020): [RID#18]
2045: [1432158308][Unknown code UUz 100]
(2022-06-09 14:51:22): [krb5_child[1808]] [map_krb5_error] (0x0020): [RID#18]
[1432158308][PAC check failed].
(2022-06-09 14:51:22): [krb5_child[1808]] [k5c_send_data] (0x0200): [RID#18]
Received error code 1432158308
(2022-06-09 14:51:22): [krb5_child[1808]] [pack_response_packet] (0x2000):
[RID#18] response packet size: [20]
(2022-06-09 14:51:22): [krb5_child[1808]] [k5c_send_data] (0x4000): [RID#18]
Response sent.
(2022-06-09 14:51:22): [krb5_child[1808]] [main] (0x0400): [RID#18] krb5_child
completed successfully
I had to rollback the system to before the update for now but am willing to
attempt again if additional data is needed.
--
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=2095356
2 months
[Bug 2095086] New: ipa authentication fails after upgrade to 2.7.1
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2095086
Bug ID: 2095086
Summary: ipa authentication fails after upgrade to 2.7.1
Product: Fedora
Version: 36
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: dennis(a)ausil.us
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:
after upgrade of sssd from 2.7.0-1.fc36 to 2.7.1-1.fc36 I was unable to
successfully authenticate. downgrading allowed authentication to work again
Version-Release number of selected component (if applicable):
sssd-2.7.1-1.fc36
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Jun 08 20:11:11 adria.ausil.us systemd[1]: Started sssd.service - System
Security Services Daemon.
Jun 08 20:11:14 adria.ausil.us sssd_be[665011]: GSSAPI client step 1
Jun 08 20:11:14 adria.ausil.us sssd_be[665011]: GSSAPI client step 1
Jun 08 20:11:14 adria.ausil.us sssd_be[665011]: GSSAPI client step 1
Jun 08 20:11:14 adria.ausil.us sssd_be[665011]: GSSAPI client step 2
Jun 08 20:11:35 adria.ausil.us krb5_child[665561]: Unknown code UUz 100
Jun 08 20:12:28 adria.ausil.us krb5_child[665845]: Unknown code UUz 100
Jun 08 20:12:50 adria.ausil.us krb5_child[665987]: Unknown code UUz 100
Expected results:
Additional info:
--
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=2095086
2 months
[Bug 2095228] New: sssd_krb5 2.7.1 crashes "PAC check failed"
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2095228
Bug ID: 2095228
Summary: sssd_krb5 2.7.1 crashes "PAC check failed"
Product: Fedora
Version: 36
Hardware: x86_64
OS: Linux
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: seanmottles(a)posteo.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,
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 1888304
--> https://bugzilla.redhat.com/attachment.cgi?id=1888304&action=edit
sssd krb5 log file
Description of problem:
Attempting to authenticate via password on Fedora 36 host connected to FreeIPA
with sssd 2.7.1-1 fails. ID lookups still function as normal.
Version-Release number of selected component (if applicable):
sssd-2.7.1-1.fc36
How reproducible:
Every attempt.
Steps to Reproduce:
1. Connect host to FreeIPA
2. Attempt to auth FreeIPA user via password
3.
Actual results:
"System Error" in /var/log/secure, and "PAC check failed for principal" in
/var/log/sssd/krb5_child.log
Expected results:
Password auth is functional
Additional info:
Downgrading sssd to 2.7.0 resolves the issue and users can login as normal.
--
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=2095228
2 months
[Bug 2095176] New: sssd 2.7.1 cannot do Kerberos authentication [regression]
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2095176
Bug ID: 2095176
Summary: sssd 2.7.1 cannot do Kerberos authentication
[regression]
Product: Fedora
Version: 36
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,
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:
There is unfortunately something seriously broken in Kerberos part in sssd
2.7.1.
We get the following in the auth log:
> jun 09 08:43:48 samuel krb5_child[259734]: Unknown code UUz 100
> jun 09 08:43:48 samuel gdm-password][259724]: pam_sss(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=samuel
> jun 09 08:43:48 samuel gdm-password][259724]: pam_sss(gdm-password:auth): received for user samuel: 4 (System error)
In sssd's log:
> (2022-06-09 8:43:48): [be[cendio.se]] [krb5_auth_done] (0x3f7c0): [RID#331] The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information
And in the krb5 child log:
> (2022-06-09 8:43:57): [krb5_child[259752]] [sss_extract_pac] (0x0040): [RID#333] No PAC authdata available.
> ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
> * (2022-06-09 8:43:57): [krb5_child[259752]] [main] (0x0400): [RID#333] krb5_child started.
> * (2022-06-09 8:43:57): [krb5_child[259752]] [unpack_buffer] (0x1000): [RID#333] total buffer size: [109]
> * (2022-06-09 8:43:57): [krb5_child[259752]] [unpack_buffer] (0x0100): [RID#333] cmd [241 (auth)] uid [4036] gid [21031] validate [true] enterprise principal [false] offline [false] UPN [samuel(a)CENDIO.SE]
> * (2022-06-09 8:43:57): [krb5_child[259752]] [unpack_buffer] (0x0100): [RID#333] ccname: [KCM:] old_ccname: [KCM:] keytab: [/etc/krb5.keytab]
> * (2022-06-09 8:43:57): [krb5_child[259752]] [switch_creds] (0x0200): [RID#333] Switch user to [4036][21031].
> * (2022-06-09 8:43:57): [krb5_child[259752]] [switch_creds] (0x0200): [RID#333] Switch user to [0][0].
> * (2022-06-09 8:43:57): [krb5_child[259752]] [k5c_check_old_ccache] (0x4000): [RID#333] Ccache_file is [KCM:] and is active and TGT is valid.
> * (2022-06-09 8:43:57): [krb5_child[259752]] [k5c_setup_fast] (0x0100): [RID#333] Fast principal is set to [host/samuel.lkpg.cendio.se(a)CENDIO.SE]
> * (2022-06-09 8:43:57): [krb5_child[259752]] [find_principal_in_keytab] (0x4000): [RID#333] Trying to find principal host/samuel.lkpg.cendio.se(a)CENDIO.SE in keytab.
> * (2022-06-09 8:43:57): [krb5_child[259752]] [match_principal] (0x1000): [RID#333] Principal matched to the sample (host/samuel.lkpg.cendio.se(a)CENDIO.SE).
> * (2022-06-09 8:43:57): [krb5_child[259752]] [check_fast_ccache] (0x0200): [RID#333] FAST TGT is still valid.
> * (2022-06-09 8:43:57): [krb5_child[259752]] [become_user] (0x0200): [RID#333] Trying to become user [4036][21031].
> * (2022-06-09 8:43:57): [krb5_child[259752]] [main] (0x2000): [RID#333] Running as [4036][21031].
> * (2022-06-09 8:43:57): [krb5_child[259752]] [set_lifetime_options] (0x0100): [RID#333] No specific renewable lifetime requested.
> * (2022-06-09 8:43:57): [krb5_child[259752]] [set_lifetime_options] (0x0100): [RID#333] No specific lifetime requested.
> * (2022-06-09 8:43:57): [krb5_child[259752]] [set_canonicalize_option] (0x0100): [RID#333] Canonicalization is set to [true]
> * (2022-06-09 8:43:57): [krb5_child[259752]] [main] (0x0400): [RID#333] Will perform auth
> * (2022-06-09 8:43:57): [krb5_child[259752]] [main] (0x0400): [RID#333] Will perform online auth
> * (2022-06-09 8:43:57): [krb5_child[259752]] [tgt_req_child] (0x1000): [RID#333] Attempting to get a TGT
> * (2022-06-09 8:43:57): [krb5_child[259752]] [get_and_save_tgt] (0x0400): [RID#333] Attempting kinit for realm [CENDIO.SE]
> * (2022-06-09 8:43:57): [krb5_child[259752]] [sss_krb5_responder] (0x4000): [RID#333] Got question [password].
> * (2022-06-09 8:43:57): [krb5_child[259752]] [validate_tgt] (0x2000): [RID#333] Found keytab entry with the realm of the credential.
> * (2022-06-09 8:43:57): [krb5_child[259752]] [validate_tgt] (0x0400): [RID#333] TGT verified using key for [host/samuel.lkpg.cendio.se(a)CENDIO.SE].
> * (2022-06-09 8:43:57): [krb5_child[259752]] [sss_extract_pac] (0x0040): [RID#333] No PAC authdata available.
> ********************** BACKTRACE DUMP ENDS HERE *********************************
>
> (2022-06-09 8:43:57): [krb5_child[259752]] [validate_tgt] (0x0020): [RID#333] PAC check failed for principal [samuel(a)CENDIO.SE].
> (2022-06-09 8:43:57): [krb5_child[259752]] [get_and_save_tgt] (0x0020): [RID#333] 2045: [1432158308][Unknown code UUz 100]
> ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
> * (2022-06-09 8:43:57): [krb5_child[259752]] [validate_tgt] (0x0020): [RID#333] PAC check failed for principal [samuel(a)CENDIO.SE].
> * (2022-06-09 8:43:57): [krb5_child[259752]] [get_and_save_tgt] (0x0020): [RID#333] 2045: [1432158308][Unknown code UUz 100]
> ********************** BACKTRACE DUMP ENDS HERE *********************************
>
> (2022-06-09 8:43:57): [krb5_child[259752]] [map_krb5_error] (0x0020): [RID#333] [1432158308][PAC check failed].
Version-Release number of selected component (if applicable):
sssd-2.7.1-1.fc36.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Upgrade sssd
2. Try to log in
Actual results:
Login fails
Expected results:
Login succeeds
Additional info:
Also reported to debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012502
Which also references this upstream PR:
https://github.com/SSSD/sssd/pull/6204
--
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=2095176
2 months
[Bug 2095102] New: SSSD 2.7.1 causes IPA/krb5 authentication to fail with messages such as the following in /var/log/sssd/sssd_DOMAIN.log
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2095102
Bug ID: 2095102
Summary: SSSD 2.7.1 causes IPA/krb5 authentication to fail
with messages such as the following in
/var/log/sssd/sssd_DOMAIN.log
Product: Fedora
Version: 36
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: plarsen(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:
This issue is replicated in this BZ:
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1857082...
After updating to sssd to 2.7.1-1 logins using GDM to an IPA user fails.
Error in krb5_child.log:
* (2022-06-08 23:28:04): [krb5_child[4535]] [sss_krb5_responder] (0x4000):
[RID#22] Got question [password].
* (2022-06-08 23:28:04): [krb5_child[4535]] [sss_krb5_expire_callback_func]
(0x2000): [RID#22] exp_time: [10364636]
* (2022-06-08 23:28:04): [krb5_child[4535]] [validate_tgt] (0x2000):
[RID#22] Found keytab entry with the realm of the credential.
* (2022-06-08 23:28:04): [krb5_child[4535]] [validate_tgt] (0x0400):
[RID#22] TGT verified using key for
[host/boss.peterlarsen.org(a)PETERLARSEN.ORG].
* (2022-06-08 23:28:04): [krb5_child[4535]] [sss_extract_pac] (0x0040):
[RID#22] No PAC authdata available.
********************** BACKTRACE DUMP ENDS HERE
*********************************
(2022-06-08 23:28:04): [krb5_child[4535]] [validate_tgt] (0x0020): [RID#22] PAC
check failed for principal [peter(a)PETERLARSEN.ORG].
(2022-06-08 23:28:04): [krb5_child[4535]] [get_and_save_tgt] (0x0020): [RID#22]
2045: [1432158308][Unknown code UUz 100]
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING
BACKTRACE:
* (2022-06-08 23:28:04): [krb5_child[4535]] [validate_tgt] (0x0020):
[RID#22] PAC check failed for principal [peter(a)PETERLARSEN.ORG].
* (2022-06-08 23:28:04): [krb5_child[4535]] [get_and_save_tgt] (0x0020):
[RID#22] 2045: [1432158308][Unknown code UUz 100]
********************** BACKTRACE DUMP ENDS HERE
*********************************
Version-Release number of selected component (if applicable):
2.7.1-1
How reproducible:
Constant
Steps to Reproduce:
1. Update from 2.7.0-1 to 2.7.1-1
2.
3.
Actual results:
Login via GDM not possible
Expected results:
Login working
Additional info:
Downgrading to 2.7.0-1 allowed GDM to work again.
Note, applying https://access.redhat.com/solutions/2210951 did not resolve the
issue.
--
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=2095102
2 months
[Bug 2094948] New: Unable to log in to accounts from CentOS 7 FreeIPA Server
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2094948
Bug ID: 2094948
Summary: Unable to log in to accounts from CentOS 7 FreeIPA
Server
Product: Fedora
Version: 36
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: mheon(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:
I have a CentOS 7 FreeIPA server (ipa-server-4.6.8-5.el7.centos.10.x86_64,
other RPM versions available on request), with several systems joined to the
domain (F35, F36, and CentOS 7). I recently performed a dnf upgrade on one of
the F36 systems, which pulled in sssd 2.7.1 (was previously on 2.7.0). After
the upgrade, I became unable to log into any IPA account. Relevant error
messages below:
Jun 08 11:34:27 Bellerophon.int.lldp.net krb5_child[14823]: Unknown code UUz
100
Jun 08 11:34:27 Bellerophon.int.lldp.net gdm-password][14818]:
pam_sss(gdm-password:auth): authentication failure; logname= uid=0 euid=0
tty=/dev/tty1 ruser= rhost= user=mheon
Jun 08 11:34:27 Bellerophon.int.lldp.net gdm-password][14818]:
pam_sss(gdm-password:auth): received for user mheon: 4 (System error)
Jun 08 11:34:27 Bellerophon.int.lldp.net gdm-password][14818]: gkr-pam:
unlocked login keyring
All other systems on the domain remained able to log in. No error messages are
visible in the IPA server's journal. Downgrading to sssd-2.7.0-1.fc36.x86_64
resolves the issue and restores the ability to log in. I do not have another
IPA server to test with at the moment, but I did confirm that unenrolling and
reenrolling the host in question (in hopes of replacing any faulty
configuration files written) did not resolve the problem.
Notably, this occurs only for login attempts via password (from TTY or
graphical session). Logging in using SSH with key authentication works. Once
logged in via SSH, I am able to communicate with at least the IPA server's
Kerberos server (e.g. `kinit mheon` works).
Version-Release number of selected component (if applicable):
sssd-2.7.1-1.fc36.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Upgrade to sssd 2.7.1
2. Log out
3. Log into an IPA-managed account
Actual results:
Login fails
Expected results:
Login succeeds
Additional info:
I don't know if this is sssd itself or a subpackage (sssd-ipa seems likely?) -
apologies if this should have been filed elsewhere.
--
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=2094948
2 months
[Bug 2094648] New: [Regression] Can't log in to FreeIPA account following sssd update
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2094648
Bug ID: 2094648
Summary: [Regression] Can't log in to FreeIPA account following
sssd update
Product: Fedora
Version: 36
Status: NEW
Component: sssd
Severity: urgent
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: james(a)ettle.org.uk
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:
Updating to sssd 2.7.1-1.fc36 from sssd-2.7.0-1 breaks login to my FreeIPA
accounts.
Version-Release number of selected component (if applicable):
sssd and friends 2.7.1-1.fc36
How reproducible:
Always.
Steps to Reproduce:
1. Update to sssd 2.7.1-1.fc36
2. Reboot.
Actual results:
Permission denied for FreeIPA realm account.
Expected results:
Legitimate login works.
--
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=2094648
2 months, 1 week