I need to prepare/update system trust bundles in kubernetes pods, preferably as an unprivileged user (since k8s volumes provide a way to mount a writeable path on any location such as /etc/pki). The optimal way to enable this would be if update-ca-trust could have some --extract-dir option so that I could specify an alternative location to write the extracted dir to, as an unprivileged user: update-ca-trust --extract-dir /mnt/etc/pki/ca-trust/extracted Which would write the extracted contents to a volume that could then be mounted on /etc/pki/ca-trust/extracted in the run container. However if that is not feasible, an alternative solution would also be possible via a minimal bug fix. The 'steps to reproduce' field shows that update-ca-trust must be chmodding the /etc/pki/ca-trust/extracted/pem/directory-hash to make it unwriteable, then attempting to write in that directory. If run as root it normally works because root can always write, but running as an unprivileged user exposes the bug. It should change the directory permissions to make it unwriteable after it finishes writing to the directory. It would also be very helpful if update-ca-trust would create the dirs that it expects to exist so the mkdir steps would not be required. If they do not exist it just fails, even if it has permission to create them because I chowned /etc/pki/ca-trust/extracted: $ update-ca-trust p11-kit: couldn't create file: /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt: Unknown error 2 p11-kit: couldn't create file: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem: Unknown error 2 p11-kit: couldn't create file: /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem: Unknown error 2 p11-kit: couldn't create file: /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem: Unknown error 2 p11-kit: couldn't create file: /etc/pki/ca-trust/extracted/java/cacerts: Unknown error 2 p11-kit: couldn't create file: /etc/pki/ca-trust/extracted/edk2/cacerts.bin: Unknown error 2 p11-kit: couldn't create directory: /etc/pki/ca-trust/extracted/pem/directory-hash: Unknown error 2 p11-kit: couldn't open directory: /etc/pki/ca-trust/extracted/pem/directory-hash: Unknown error 2 Reproducible: Always Steps to Reproduce: On Fedora 38 with ca-certificates-2023.2.60-2.fc38.noarch $ whoami fedora $ sudo rm -rf /etc/pki/ca-trust/extracted/* $ sudo chown fedora: /etc/pki/ca-trust/extracted/ $ mkdir -p /etc/pki/ca-trust/extracted/openssl /etc/pki/ca-trust/extracted/java /etc/pki/ca-trust/extracted/edk2 /etc/pki/ca-trust/extracted/pem/directory-hash $ ls -ld /etc/pki/ca-trust/extracted/pem/directory-hash drwxr-xr-x. 1 fedora fedora 0 Sep 28 19:22 /etc/pki/ca-trust/extracted/pem/directory-hash Actual Results: $ update-ca-trust # unprivileged /usr/bin/ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-certificates.crt': Permission denied /usr/bin/ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-bundle.crt': Permission denied $ ls -ld /etc/pki/ca-trust/extracted/pem/directory-hash dr-xr-xr-x. 1 fedora fedora 14064 Sep 28 19:23 /etc/pki/ca-trust/extracted/pem/directory-hash The directory was writeable at first, then update-ca-trust made it unwriteable, then update-ca-trust failed because it could not write to it. Expected Results: $ update-ca-trust # unprivileged $ echo $? 0
Until it doesn't, here's a thing that works for me $ mkdir -p rw-dir/{edk2,java,openssl,pem} $ unshare -rm sh -c 'mount --bind rw-dir /etc/pki/ca-trust/extracted && update-ca-trust'
p11-kit trust makes the directory unwritable after updating its contents: https://github.com/p11-glue/p11-kit/blob/master/trust/save.c#L362-L385 https://github.com/p11-glue/p11-kit/blob/master/trust/save.c#L627-L634 So the issue here is in the update-ca-trust script.
This was a fun exercise, PR at https://src.fedoraproject.org/rpms/ca-certificates/pull-request/8. Bob, would you mind reviewing?
So here's the deal, in general we don't want someone to run update-ca-trust as a non-privelleged user. Running this changes the trusted roots for everyone on the system. So the fundamental ask is flawed, we won't just be making update-ca-trust work for anyone. That being said. Clemen's patch is a generally good idea for solving this (with some tweaks). It doesn't actually meant what the bug says, but it does provide a way for the user to get what they want in the container. To be clear: Expected Results: $ update-ca-trust # unprivileged $ echo $? 0 is never going to happen anymore then Expected Results: $ su #unprivileged, no password # whoami # root is never going to happen.
Fear not, I am fully aware of the security implications of running update-ca-trust on a conventional Linux system and am not suggesting unprivileged users should be able to normally run it in that context. However, the code does not exist solely in the context of a conventional Linux system. IMHO update-ca-trust should just be a tool to read and write cert files, and it is the responsibility of the operating environment to enforce appropriate security policies e.g. via ownership and permissions of system directories. I am very grateful to see the --output option being discussed and implemented <3 and I think this illustrates a clearer delineation of the relevant security considerations than my "hack" of sudo chown fedora: /etc/pki/ca-trust/extracted/ Thank you for supporting container-native solutions!
Yeah, My comment is more of an expectation. As originally written, the expected results is clearly not what we want. Adding a feature to update-ca-trust which lets it run on an arbitrary directory (and thus carry the existing protections from the filesystem).
FEDORA-2023-0f2f12457f has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-0f2f12457f
FEDORA-2023-271dd7d5f4 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-271dd7d5f4
FEDORA-2023-271dd7d5f4 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.