|Summary:||hardcodes administrator group name|
|Product:||accountsservice||Reporter:||Bill Nottingham <notting>|
|Component:||general||Assignee:||Matthias Clasen <mclasen>|
|Status:||RESOLVED WONTFIX||QA Contact:|
|i915 platform:||i915 features:|
Description Bill Nottingham 2011-03-16 14:05:46 UTC
accountsservice hardcodes desktop_admin_r and desktop_user_r. However, desktop_admin_r's significance is a local PolKit configuration item, set by distro or administrator defaults: $ cat /etc/polkit-1/localauthority.conf.d/60-desktop-policy.conf # This allows users in the desktop_admin_r group to authenticate as # the administrator. # # DO NOT EDIT THIS FILE, it will be overwritten on update. [Configuration] AdminIdentities=unix-group:desktop_admin_r (which can be overridden in site config). accountsservice needs to take this into account and use the correct configured value for the system.
Comment 1 Ray Strode [halfline] 2011-03-17 10:47:58 UTC
*** This bug has been marked as a duplicate of bug 35390 ***
Comment 2 Bill Nottingham 2011-03-17 11:12:24 UTC
Reopening - 35390 merely changes what group is hardcoded.
Comment 3 David Zeuthen (not reading bugmail) 2011-03-17 11:43:55 UTC
Hmm. I think we want to continue to hardcode this.. to nudge distros in the direction of doing the same thing... e.g. use the wheel group.. suggest WONTFIX
Comment 4 Matthias Clasen 2011-03-17 11:54:49 UTC
I concur; after ditching desktop_admin_r and desktop_user_r and changing to wheel, there seems little reason not to hardcode this.
Comment 5 Bill Nottingham 2011-03-17 11:55:26 UTC
If we do that, then, what's the purpose of having a local override that breaks the tools?
Comment 6 David Zeuthen (not reading bugmail) 2011-03-17 12:03:09 UTC
(In reply to comment #5) > If we do that, then, what's the purpose of having a local override that breaks > the tools? Well, PolicyKit will use the wheel group _only_ if polkit-desktop-policy is installed. If a) that isn't the case; or b) another file in /etc/polkit-1/localauthority.conf.d changes AdminIdentities from underneat us then all bets are off and the OS cannot be expected to work as designed. There are legitimate reasons for this kind of configuration, just as there are legitimate reasons for disabling the root account, removing suid bits or other things that "breaks" some tools. In particular, if people don't like the fact that PolicyKit gives special powers to people in 'wheel', the quick answer is "remove the polkit-desktop-policy package".
Comment 7 Ray Strode [halfline] 2011-03-17 12:43:21 UTC
sound enough reasoning for me.