On Sa, 23.11.24 02:40, Jesse Crawford (jesse@xxxxxxxxxxxxx) wrote: (2nd offlist reply) > 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? BTW, unrelated to your specific question: I was wondering if you had a look at this stuff: https://systemd.io/USER_GROUP_API/ And maybe would be interested to hook up kanidm to that? Basically, on systemd systems you can then have rich user records that can carry any fields you want, and systemd's components (such as systemd-logind) will enforce a bunch of them, that previously weren't available. I was also wondering: in systemd we try to clean up the mess we are currently in regarding UID range allocation, and documented clearly what the expectations are that systemd has on this. Hence I was wondering, from which UID range does kanidm allocate the UIDs it assigns? Can we come to some agreement on this so that for each purpose we have clearly separated UID ranges and we don't step on each others toes? (I am basically talking about this stuff: https://systemd.io/UIDS-GIDS/) Background: IPA folks are very negative about all this, I think they kinda are offended by the fact we are trying to clean these things up. They really insist that IPA/SSSS owns the whole UID range, and they define the Linux user database, which um, is not how I see things, I'd rather have a more pluralistic view, that we agree on rules, and everyone can have their UID range without conflicts (at least in future, I am fully aware that legacy installations allocate from all kind of ranges). Anyway, if you are interested in working with us on this, would be happy to! For example, if you think that exposing JSON user group records via said API would be an option for kanidm, then I'd be happy to add the fields you need to the spec (i.e. this spec: https://systemd.io/USER_RECORD/) 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
