Description of problem: When the system policy allows the user to install packages, he shouldn't be asked for a password when he chooses to update the system. (By the way, is it possible to limit the privilege to install packages to packages signed with known gpg keys only?)
>shouldn't be asked for a password when he chooses to update the system I don't think it's possible to infer an auth with PolicyKit - davidz? >install packages to packages signed with known gpg keys only Not yet, but it's in progress. See #440060
(In reply to comment #1) > >install packages to packages signed with known gpg keys only > > Not yet, but it's in progress. See #440060 Right, this is important to fix. Users should never ever be able to retain authorizations to install packages not signed by a trusted key. > >shouldn't be asked for a password when he chooses to update the system > > I don't think it's possible to infer an auth with PolicyKit - davidz? Sure it is. You can just check for both authorizations in your mechanism's Update() method. Do remember the reverse is certainly not true (right to update does not imply right to install) and would be a security bug if it did. Also PolKitGnomeAction would need to support feeding it with more than one authorization, e.g. http://hal.freedesktop.org/docs/PolicyKit-gnome/PolKitGnomeAction.html#PolKitGnomeAction--polkit-action currently only takes a single action. And you'd need to return two actions in the D-Bus exception if the caller lacks both of these. As such, I don't think this is interesting to address because it would complicate some pretty security-critical code paths for little gain. And once bug 440060 is resolved updating the system with packages signed by a trusted key shouldn't need to require any password by default. So once this is resolved no ordinary setups will run into this. Of course once bug 440060 is resolved you may consider just collapsing update and install into a single action. Because I can only think of contrived examples where you want a user to be authorized for one but not the other. Can you think of any? Anyway, it's normally always a good idea to keep the number of actions low to avoid corner cases like the one reported here. Also to avoid confusing users / sysadmins and generally keep the security sensitive codepaths simple. Less is more. Etc. etc.. Ideally you'd have only actions install install-untrusted manage-gpg-keys manage-repositories where only the first one can be retained by the user.
>I can only think of contrived examples where you want a user to be authorized for one but not the other. Can you think of any? Well, if you lump this together you don't get the "right" titles and messages on the policykit auth prompt - but other than that I agree with you.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've fixed this in 0.3.0 which should be in rawhide today.