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.comDOMAIN=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.
https://bugzilla.redhat.com/show_bug.cgi?id=2325893
Bug ID: 2325893
Summary: sssd gpo_child doesn't have sufficient rights to
populate GPO policies
Product: Fedora
Version: 41
Hardware: x86_64
OS: Linux
Status: NEW
Component: sssd
Keywords: CommonBugs, Desktop
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: nekopilot(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.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
# 1. Issue
After upgrade from F39 to F41 via UI path the login to the system with AD
account is not possible. Local account works well.
# 2. Workaround
sssd service works under sssd user in Fedora 41. The folder with GPO policies
has wrong rights with owner root:
ls -lah /var/lib/sss/gpo_cache/example.com/Policies/
total 0
drwx------. 4 root root 98 Jan 10 2024 .
drwx------. 3 sssd sssd 22 Jan 10 2024 ..
drwx------. 3 root root 36 Nov 13 07:33 {31B2F332-016D-11D2-945F-00C04FBB84F9}
drwx------. 3 root root 36 Nov 13 07:33 {7E50761D-1E4D-4D2B-BD86-E667EED3DF1E}
It is possible to change the owner of the directories. After that the login
with AD account works well.
chown -R sssd:sssd /var/lib/sss/gpo_cache
Reproducible: Always
Steps to Reproduce:
1. Your F39 system must be joined to AD with sssd and you can login to the
system with AD account.
2. Upgrade from F39 to F41.
3. Try to login with AD account.
Actual Results:
Login from Gnome UI is not possible with error: "Wrong user name or password".
Expected Results:
You can login to the system with AD account.
Your F39 system must be joined to AD with sssd and you can login to the system
with AD account.
After upgrade you can't login from UI with AD account but:
1. kinit user.name(a)example.com - works well.
1. id user.name(a)example.com - works well.
1. realm list - looks good.
In logs you can find error message:
cat /var/log/sssd/gpo_child.log
```
[gpo_child[4066]] [prepare_gpo_cache] (0x0020): [RID#23]
mkdir(/var/lib/sss/gpo_cache/example.com/Policies/{31B2F332-016D-11D2-945F-…
failed: 13
```
--
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=2325893
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2319608
Bug ID: 2319608
Summary: python3-sssdconfig packs outdated .pyc files
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: sssd
Keywords: Regression
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: jpazdziora(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.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
The /usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/*.cpython-313.pyc
/usr/lib/files get regenerated when SSSDConfig module is used.
Reproducible: Always
Steps to Reproduce:
1. dnf install -y python3-sssdconfig
2. stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
3. python3 -c 'import SSSDConfig'
4. stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Actual Results:
[root@0890eef375bc /]# stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
File:
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Size: 57759 Blocks: 120 IO Block: 4096 regular file
Device: 0,109 Inode: 1226072 Links: 2
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-10-15 00:00:00.000000000 +0000
Modify: 2024-10-15 00:00:00.000000000 +0000
Change: 2024-10-18 09:46:42.433097566 +0000
Birth: 2024-10-18 09:46:42.432097551 +0000
[root@0890eef375bc /]# python3 -c 'import SSSDConfig'
[root@0890eef375bc /]# stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
File:
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Size: 59402 Blocks: 120 IO Block: 4096 regular file
Device: 0,109 Inode: 1196042 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-10-18 09:47:14.646592272 +0000
Modify: 2024-10-18 09:47:14.646592272 +0000
Change: 2024-10-18 09:47:14.646592272 +0000
Birth: 2024-10-18 09:47:14.646592272 +0000
Expected Results:
The Size and Modify time in the second stat run should match the output from
the first one.
First found by
https://github.com/freeipa/freeipa-container/actions/runs/11397511703/job/3….
--
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=2319608
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2334868
Bug ID: 2334868
Summary: updating an existing system to sssd-2.10.1 causes sssd
to fail with permissions issues
Product: Fedora
Version: 41
OS: Linux
Status: NEW
Component: sssd
Keywords: Upgrades
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: roth(a)ursus.net
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(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
[this is on a ostree system (Fedora 41 Kinoite)]
From what I can tell, the sssd permissions changed recently from root:sssd to
sssd:sssd, and there are subtle differences in the way the config directories
and config files are owned that cause the most recent update to fail.
The previous version (2.10.0) had /etc/sssd at mode 0700, owned by root:sssd.
Now that the service runs as sssd:sssd it is not able to access previous
configs in /etc/sssd and the daemon fails with a permissions error.
There are a couple of contributing factors to this update failure:
1. the three-way merge for /etc files done by ostree does not preserve file
permissions, and does not update directory permissions. When /usr/etc/sssd
changed from 0700 to 0750, this was not reflected in /etc/sssd.
2. the ExecStartPre= statements in sssd.service are a bit optimistic. The chown
and chmod commands don't work with the current service settings (User= and
Group=). They currently fail but this is masked by the '-f' option.
I was able to fix this on my local system by (1) commenting out the
ExecStartPre= statements and (2) moving them to a dependent service that runs
as root. I guess this could also be accomplished with
PermissionsStartOnly=true.
Reproducible: Always
Steps to Reproduce:
1. build up a system that uses sssd (fully-populated /etc/sssd/sssd.conf)
2. stop sssd
3. chmod 0700 /etc/sssd
4. chown root:sssd /etc/sssd
5. try to start sssd
Actual Results:
sssd does not start, it is not able to correctly re-own the files and
directories it needs.
Here is the update report from the most recent ostree transaction
$ rpm-ostree db diff
ostree diff commit from: rollback deployment
(5796a4d9fbff9b2d0e28f34070e6958e0cfb5a1b3ab702fd1ed318ade3aa91ef)
ostree diff commit to: booted deployment
(f07128cd02dc40fbe578714f095140f44e5986f98902783d00bbd837a0ed06d6)
Upgraded:
cldr-emoji-annotation 1:46.1~beta2-1.fc41 -> 1:46.1-1.fc41
cldr-emoji-annotation-dtd 1:46.1~beta2-1.fc41 -> 1:46.1-1.fc41
ibus-typing-booster 2.27.1-1.fc41 -> 2.27.2-1.fc41
intel-vpl-gpu-rt 24.3.4-1.fc41 -> 24.4.4-1.fc41
libsss_certmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
libsss_idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
libsss_nss_idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
libsss_sudo 2.10.0-2.fc41 -> 2.10.1-1.fc41
libva-intel-media-driver 24.3.4-1.fc41 -> 24.4.4-1.fc41
libvpl 1:2.13.0-1.fc41 -> 1:2.14.0-1.fc41
libxml2 2.12.8-2.fc41 -> 2.12.9-1.fc41
openjpeg 2.5.3-1.fc41 -> 2.5.3-2.fc41
setup 2.15.0-5.fc41 -> 2.15.0-8.fc41
sssd-client 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-common 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-kcm 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-krb5-common 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-ldap 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-nfs-idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
--
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=2334868
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2320042
Bug ID: 2320042
Summary: [abrt] sssd-tools: set_component():
source_files.py:73:set_component:OSError
Product: Fedora
Version: 41
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:a5a6dd78a14a8d86bce922d86636e1cb2da53ec6;VAR
IANT_ID=workstation;
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: maxi(a)maxiicodes.dev
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.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
Version-Release number of selected component:
sssd-tools-2.10.0-1.fc41
Additional info:
reporter: libreport-2.17.15
kernel: 6.11.4-300.fc41.x86_64
cmdline: /usr/bin/python3 -sP /usr/libexec/sssd/sss_analyze error list
cgroup:
0::/user.slice/user-1000.slice/user@1000.service/app.slice/app-cosmic-com.system76.CosmicAppList-3787.scope
uid: 1000
reason: source_files.py:73:set_component:OSError
executable: /usr/libexec/sssd/sss_analyze
type: Python3
package: sssd-tools-2.10.0-1.fc41
runlevel: N 5
exception_type: OSError
crash_function: set_component
interpreter: python3-3.13.0-1.fc41.x86_64
Truncated backtrace:
source_files.py:73:set_component:OSError
Traceback (most recent call last):
File "/usr/libexec/sssd/sss_analyze", line 5, in <module>
sss_analyze.run()
~~~~~~~~~~~~~~~^^
File "/usr/lib/python3.13/site-packages/sssd/sss_analyze.py", line 107, in
run
analyzer.main()
~~~~~~~~~~~~~^^
File "/usr/lib/python3.13/site-packages/sssd/sss_analyze.py", line 102, in
main
args.func(args)
~~~~~~~~~^^^^^^
File "/usr/lib/python3.13/site-packages/sssd/modules/error.py", line 52, in
print_error
source.set_component(component, False)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.13/site-packages/sssd/source_files.py", line 73, in
set_component
raise IOError
OSError
Local variables in innermost frame:
self: <sssd.source_files.Files object at 0x7f0cd2976e40>
component: <Component.BE: 3>
child: False
domains: []
--
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=2320042
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2334087
Bug ID: 2334087
Summary: Capabilities related changes in
sssd-2.10.1-2.fc42.x86_64 break SSSD in containers
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: sssd
Keywords: Regression
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: adelton(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(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
We are running the FreeIPA containers in GitHub Actions of
https://github.com/freeipa/freeipa-container. With sssd 2.10.0-3.fc42 packages
in Fedora rawhide the
https://github.com/freeipa/freeipa-container/actions/runs/12461283683 run
passed, with sssd 2.10.1-2.fc42 the
https://github.com/freeipa/freeipa-container/actions/runs/12489404343 started
to fail for rawhide, on all runtimes.
It is also easy to reproduce the issue locally with
tests/run-partial-tests.sh Dockerfile.fedora-rawhide
In /var/log/sssd/ldap_child.log I then see
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING
BACKTRACE:
* (2024-12-25 16:41:58): [ldap_child[6484]] [sss_log_process_caps]
(0x0100): Starting under ruid=285, euid=285, suid=285 : rgid=284, egid=284,
sgid=284
* (2024-12-25 16:41:58): [ldap_child[6484]] [sss_log_process_caps]
(0x0100): With following capabilities:
(nothing)
* (2024-12-25 16:41:58): [ldap_child[6484]] [main] (0x2000): context
initialized
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): total
buffer size: 56
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
command: Select principal
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
realm_str size: 12
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): got
realm_str: EXAMPLE.TEST
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
princ_str size: 16
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): got
princ_str: ipa.example.test
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
keytab_name size: 0
* (2024-12-25 16:41:58): [ldap_child[6484]] [sss_set_cap_effective]
(0x0400): cap_set_proc() failed: 1 ('Operation not permitted')
* (2024-12-25 16:41:58): [ldap_child[6484]] [select_principal_from_keytab]
(0x0200): trying to select the most appropriate principal from keytab
* (2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab]
(0x0020): krb5_kt_start_seq_get failed: Permission denied
********************** BACKTRACE DUMP ENDS HERE
*********************************
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [select_principal_from_keytab]
(0x0010): Failed to read keytab [FILE:/etc/krb5.keytab]: No suitable principal
found in keytab
I see capabilities and file permission related changes in
https://github.com/SSSD/sssd/commits/master/ and in
https://src.fedoraproject.org/rpms/sssd/c/80a939719c9fd4226e7eefc0d3d93c494….
I am able to workaround the issue by reverting the capabilities back to those I
see in sssd 2.10.0-2.fc41, namely
setcap cap_chown,cap_dac_read_search,cap_setgid,cap_setuid=ep
/usr/libexec/sssd/krb5_child
setcap cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep
/usr/libexec/sssd/ldap_child
and putting in /usr/lib/systemd/system/sssd.service.d/capabilities.conf with
[Service]
# In sssd-common-2.10.1-2.fc42.x86_64:
# CapabilityBoundingSet= CAP_SETGID CAP_SETUID CAP_DAC_READ_SEARCH
# In sssd-common-2.10.0-2.fc41.x86_64:
CapabilityBoundingSet= CAP_CHOWN CAP_DAC_OVERRIDE CAP_SETGID CAP_SETUID
CAP_DAC_READ_SEARCH
Things are not proken outside of containers.
So it seems CAP_DAC_READ_SEARCH does not work (is not enough) in containerized
setups.
Reproducible: Always
Steps to Reproduce:
1. git clone https://github.com/freeipa/freeipa-container
2. cd freeipa-container/
3. # to get the state where (a planned) workaround is not present
git checkout d062ba708896d4e0e97d28ac2681097d935cde02
4. # enable a test which does not use the external volume, to minimize impact
of that containerization feature
sed -i 's/^## # test: systemd-container-ipa-server-install.sh/# test:
systemd-container-ipa-server-install.sh/' Dockerfile.fedora-rawhide
5. docker=podman tests/run-partial-tests.sh Dockerfile.fedora-rawhide
Actual Results:
● sssd.service loaded failed failed System Security Services Daemon
Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use
systemd-escape?).
Unit \xe2\x97\x8f.service could not be found.
Yeah, it's not a good error message. It tries to say that sssd.service is
failed.
Expected Results:
No error.
I understand Fedora does not primarily ship SSSD to work in containers, so this
is mostly a headsup that recent changes in the packaging don't seem quite
compatibly with current state of container runtimes.
--
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=2334087
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2333529
Bug ID: 2333529
Summary: unpacking of archive failed on file /var/lib/sss/mc:
cpio: chown failed
Product: Fedora
Version: 41
OS: Linux
Status: NEW
Component: sssd
Keywords: Upgrades
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: gregory.lee.bartholomew(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(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
While trying to upgrade a systemd-nspawn container from Fedora 40 to Fedora 41,
I received the following error:
Upgrading : sssd-common-2.10.0-2.fc41.x86_64
495/1223
error: unpacking of archive failed on file /var/lib/sss/mc: cpio: chown failed
- No data available
The container's /var/lib/sss/mc directory is ro-bind-mounted from the host
system similar to what is described in the last post (dated 11/05/16 14:29)
here:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.…
Reproducible: Always
Steps to Reproduce:
1. dnf upgrade --releasever=41
Actual Results:
Failed:
sssd-common-2.9.5-1.fc40.x86_64
sssd-common-2.10.0-2.fc41.x86_64
Error: Transaction failed
Expected Results:
Transaction succeeded
--
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=2333529
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2305856
Bug ID: 2305856
Summary: sss_ssh_knownhosts man page does not contain
information about replacements
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: sssd
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: orion(a)nwra.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.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
ssh fails with:
******************************************************************************
Your system is configured to use the obsolete tool sss_ssh_knownhostsproxy.
Please read the sss_ssh_knownhosts(1) man page to learn about its replacement.
******************************************************************************
But man sss_ssh_knownhosts contains just:
SSS_SSH_KNOWNHOSTS(1) SSSD Manual pages
SSS_SSH_KNOWNHOSTS(1)
NAME
sss_ssh_knownhosts - get OpenSSH known hosts public keys
SYNOPSIS
sss_ssh_knownhosts [options] HOST
DESCRIPTION
sss_ssh_knownhosts acquires SSH public keys for host HOST and outputs
them in OpenSSH known_hosts key format (see the
“SSH_KNOWN_HOSTS FILE FORMAT” section of sshd(8) for more information).
ssh(1) can be configured to use sss_ssh_knownhosts for public key host
authentication using the “KnownHostsCommand”
option:
KnownHostsCommand /usr/bin/sss_ssh_knownhosts %H
Please refer to the ssh_config(5) man page for more details about this
option.
OPTIONS
-d,--domain DOMAIN
Search for host public keys in SSSD domain DOMAIN.
-?,--help
Display help message and exit.
EXIT STATUS
In case of successful execution, even if no key was found, 0 is
returned. 1 is returned in case of error.
SEE ALSO
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5),
sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5),
sssd-sudo(5), sssd-session-recording(5), sss_cache(8),
sss_debuglevel(8), sss_obfuscate(8), sss_seed(8),
sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1),
sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8).
sss_rpcidmapd(5) sssd-systemtap(5)
AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/
SSSD 07/22/2024
SSS_SSH_KNOWNHOSTS(1)
and no information about a replacement or it being obsolete.
sssd-2.10.0~beta2-3.fc41.x86_64
Reproducible: Always
--
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=2305856
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…