On Sa, 23.11.24 02:40, Jesse Crawford (jesse@xxxxxxxxxxxxx) wrote: > Hello all, I package kanidm for Fedora in a COPR for my own > use. kanidm is an identity management solution. In the most recent > version, the kanidm-unixd client was enhanced to be able to perform > authentication against the system files as well. This has various > advantages (e.g. ability to annotate local accounts with data from > the user directory), but it poses a packaging difficulty: that means > that kanidm-unixd wants to read the /etc/shadow. > > kanidm-unixd runs as a systemd service, as you would imagine. On > OpenSUSE where kanidm is mainly developed, that service has 'shadow' > in its SupplementaryGroups to allow it to read /etc/shadow and > /etc/gshadow. On Fedora, the 'shadow' group doesn't exist, and > /etc/shadow is owned root:root with 0000 permissions. This leaves me > without any obvious way to give a systemd service the ability to > read /etc/shadow. I can imagine this is not a situation that comes > up very often, but hopefully once or twice. > > Is there a best practice, or any advice, for giving a service the > ability to read /etc/shadow? I am not worried about the selinux part > because I know how to handle that, but I'm not so sure about the > actual file permissions. ACL maybe? /usr/bin/passwd is suid root on Fedora. I have no idea how kanidm is precisely organized, but if you can split out the component touching /etc/shadow relatively nicely then I think you have two options: run that component as root, i.e. which would match the essence of what suid root on /usr/bin/shadow is. Or, a bit better: run the tool as an unpriv user, but use AmbientCapabilities= to grant it the minium capabilities to make /etc/shadow changes, which are probably CAP_CHOWN + CAP_DAC_OVERRIDE. These two caps single handedly are easily escalated to full root however, hence this doesn't improve things too much, but maybe a bit (because any files the service write are unpriv owned at least) Lennart -- Lennart Poettering, Berlin -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
