Package: sssd-dbus Version: 2.6.1-1 I am testing the new FindByValidCertificate() infopipe API from 2.6.1, to provide safe certificate authentication for cockpit. During that I ran into a curious bug, where triggering p11-kit validation in sssd messes up the permissions of /var/log/sssd/p11_child.log if it exists.
I first set up an sssd.conf for a local certificate mapping rule. I don't think the details matter, the point is just that asking sssd to validate and check a certificate will trigger the p11-kit child process, which logs into /var/log/sssd/p11_child.log. Then, once that exists, a subsequent login (through ssh or VT) will scramble the log file's permissions: -rw------- 1 64 bin 1463 Dec 9 10:03 /var/log/sssd/p11_child.log After that, any subsequent attempt to do any certificate validation fails: sssd_ifp[4412]: Could not open file [/var/log/sssd/p11_child.log]. Error: [13][Permission denied] I attach a reproducer shell script that works in a clean Debian testing environment with sssd installed (I am using the current cloud image, but that shouldn't matter so much). ❗ WARNING: repr.sh scribbles over /etc/sssd/sssd.conf and creates/removes an "alice" user, so please don't run this on a production machine. In the end it fails like this: | + stat -c %u /var/log/sssd/p11_child.log | FAIL: | + [ 64 = 0 ] | + echo FAIL: | + ls -l /var/log/sssd/p11_child.log | -rw------- 1 64 bin 1463 Dec 9 10:11 /var/log/sssd/p11_child.log | + exit 1 and reproduces that broken situation. After that, calling FindByValidCertificate() again triggers the "Permission denied" error. I am filing this against Debian as I cannot reproduce this on current Fedora 35 with sssd-2.6.1-1.fc35.x86_64, i.e. exact same upstream version. Thanks, Martin
repr.sh
Description: Bourne shell script