On Tue, Apr 15, 2025 at 3:55 AM Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > > ** Details of the problem ** > > I know the summary above is dense. Let's go through an example: > > - Package opencryptoki defines group pkcs11. This group uses "dynamic > allocation", i.e. the specific numeric gid is selected when the > package is installed, taking the first unused number. > > - The package has a file in the %files payload owned by the group: > %attr(,,pkcs11) /etc/opencryptoki/strength.conf
My suggestion might be considered a bit wild, but here goes anyway: The longer I've used POSIX-like systems (and Windows, etc), the more I think that the traditional model of per-file/directory modes is wrong for almost all applications. [0] In my opinion, it's maybe a valid matter of administrative policy whether /etc/opencryptoki/strength.conf should be world-readable, but even if it is, that policy should not be expressed as a mode set on that inode. So the question is: how can one get rid of some or all those meaningful mode bits on Linux? One answer is idmapping. It's kind of expensive (it costs a vfsmount and some other in-kernel data structures), but /etc/opencryptoki could be a mount point. Maybe it shouldn't live in /etc -- this is kind-of-sort-of a /run thing. So imagine that /etc/opencryptoki was owned by root (or maybe, in a no-modes-maximalist world it was really /etc/secret/opencryptoki and /etc/secret and everything under it was only readable by root), and /run/opencryptoki was an idmapped mount. Then there would be no persistent uid/gid mode bits. /run/opencryptoki could be created by an appropriate systemd unit, and for other cases where it's used only by a specific service, the mount could be private to the service in question and wouldn't pollute the global mount namespace. I've also floated the idea that the idmap mechanism could be extended to completely ignore the source uid/gid and maybe even modes, depending on mount options (and this would obviously require privilege to create the mounts). Then /etc/opencryptoki could have whatever mode or even be on a filesystem type or configuration where there are no mode bits, and /run/opencryptoki could still have uid and gid opencryptoki and mode 0660 or whatever. (cc Aleksa -- maybe I'll eventually convince you :) ) (For those who think I'm nuts, note that every major cloud object store is pushing very strongly for a model without per-object ACLs.) --Andy [0] Yes, this includes SELinux labels. -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
