On my Fedora 12 system, the default policy for action org.freedesktop.packagekit.system-update for processes on the active console is to allow without authentication. My system is sometimes used by people I don't fully trust, so to avoid any surprises, I wanted to create a pkla file to allow group "wheel" and deny everyone else. Surprisingly, it seems to be impossible to achieve this simple configuration under the current semantics for pkla files. I could create a group containing all users /except/ "wheel", but I really shouldn't have to do that, so let's suppose no such group exists. My pkla file looks like this: [section-deny] Identity=XXX Action=org.freedesktop.packagekit.system-update ResultActive=auth_admin_keep [section-allow] Identity=unix-group:wheel Action=org.freedesktop.packagekit.system-update ResultActive=yes The question is what identity XXX to specify for the deny section. According to the "EVALUATION ORDER" section of the pklocalauthority(8) man page, the entire set of pkla files is processed once for each group and then once for the user. So what identity can I specify that is guaranteed to match all users, yet run before the allow so that the allow takes priority for users in "wheel"? The order of processing of groups is undocumented, so there is none. The current implementation appears to process groups in the reverse order of their listing in /etc/group, but I shouldn't have to rely on that. Adding support for an Identity value "everyone" that is processed before groups would solve my problem. However, I'm wondering whether the current approach of going through all files once for each group/user is useful at all. The main thing it enables is having a user deny override a group allow, which IMO is not a sound approach to security.
I think the following should work [section-deny] Identity=unix-user:* Action=org.freedesktop.packagekit.system-update ResultActive=auth_admin_keep [section-allow] Identity=unix-group:wheel Action=org.freedesktop.packagekit.system-update ResultActive=yes
I tried that. It denies the users in wheel because the final pass for the user identity matches section-deny and not section-allow.
reproduced on Fedora PolicyKit version 0.98-4.fc14. As pklocalauthority documentation says, "processing continues even after a match" so it is not possible to set defaults using "unix-user:*" and be able to return "yes" to the authentication request for a group but not everyone else. My use case is that I want to allow only a group of users to be able to mount removable media. I think the localauthority implementation could be extended with a new special group inside the configuration files like [default] Action=org.freedesktop.udisks.filesystem-mount ResultAny=no ResultInactive=no ResultActive=no The change is that no identity is supplied. These groups with no identities are considered action defaults overrides and they are processed following the same order documented for pklocalauthority, but before the group and user are validates. the final default policy overrides the defaults provided at /usr/share/polkit-1/actions/* and then group and user processing is executed
David, This bug is still present in polkit-0.96-2.el6_0.1.x86_64. Your example in comment 1 should work, but it does not. There is no way to have a default deny rule and then only allow some people. My use case is the same as in comment 3; disallow mounting removable media by default and then only allow some users. The only way to achieve this is to modify the udisks policy file, which isn't ideal.
This appears to be the same issue as https://bugs.freedesktop.org/show_bug.cgi?id=26131. Is it possible to use Identity=unix-group:* as the everybody identity?
Sorry, that should have been https://bugzilla.redhat.com/show_bug.cgi?id=812684.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/polkit/polkit/issues/61.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.