Hide Forgot
Description of problem: No easy identifiable means to deny access to items like shutdown/restart function for all users, unless user is part of specific group. 1. Deny all users access to shutdown/restart button. -and- 2. Allow specific group access to shutdown/restart button How reproducible: 100% Steps to Reproduce: 1. create /var/lib/polkit-1/localauthority/50-local.d/20-shutdown-restart.pkla [disable stop/restart] Identity=unix-user:* Action=org.freedesktop.consolekit.system.stop;org.freedesktop.consolekit.system.stop-multiple-users;org.freedesktop.consolekit.system.restart;org.freedesktop.consolekit.system.restart-multiple-users ResultActive=no [enable stop/restart] Identity=unix-group:admins Action=org.freedesktop.consolekit.system.stop;org.freedesktop.consolekit.system.stop-multiple-users;org.freedesktop.consolekit.system.restart;org.freedesktop.consolekit.system.restart-multiple-users ResultActive=yes 2.Create two test users, one having access to group admins: uid=500(user1) gid=500(user1) groups=500(user1),503(admins) uid=501(user2) gid=501(user2) groups=501(user2) 3. login verify access to shutdown/restart Actual results: The disable for "Identity=unix-user:*" seems to supersede the enable for "Identity=unix-group:admins" Neither uid has access to shutdown/restart Expected results: user1 with access to group "admins" would have access to shutdown/restart. user2 without access to group "admins would not have access to shutdown/restart. Additional info: Will post email transcript with David Zeuthen
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux.
Chris, according to pklocalauthority(8), "For each group identity, the authorization entries are consulted in order ... Finally, the authorization entries are consulted using the user identity in the same manner. Note that processing continues even after a match." I think this means that any rule you write with Identity=unix-user:(something), that matches the user, will trump every rule you write with Identity=unix-group:(something) matching a group the user is in -- which appears to be what you observed. You could take advantage of the fact that every Unix user is in at least one Unix group, and deny authorization for unix-group:* (rather than unix-user:*), then allow it for unix-group:the-cool-people. That may work, and it's what I'm about to try at my site. Also according to pklocalauthority(8) you should probably put your files under /etc/polkit-1 rather than /var/lib/polkit-1. Denying everyone but allowing a group is common enough that it should possibly be talked about before the existing example in pklocalauthority(8) about including a group but excluding some individuals. In fact, here in the DoD, I'm not supposed to grant or deny permissions to any individual user at all, but instead use groups or roles. So I'll probably never write "Identity=unix-user:bla" matches at all.
See also https://bugs.freedesktop.org/show_bug.cgi?id=26131
Hi Matthias, Can you give me your thoughts on the progress and current status of BZ? The customer asked about it 2 weeks in a row but I did not have a status for them. Any info that you can share would be helpful. Thanks. - Nick Greene.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. This request will be considered in a future release of Red Hat Enterprise Linux.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1533.html