accountsservice assumes that users in the wheel group are admins. But this is not true on all distros -- for openSUSE, the wheel group has no specific meaning. We probably need to add API to let clients know there's no admin type, though (so that g-c-c doesn't allow adding such accounts).
any chance you could change openSUSE to have that meaning?
Yes, I think there may need to be some way to hide the account type combo if there are no account types. But that is more a polkit configuration questions than an accountsservice configuration question, no ?
the issue is accountsservice assume polkit is configured a specific way and it's not on all distros. iirc, in fact, we do that "configuration" in fedora in the %build second of the spec file for polkit, which is just totally busted. honestly, we should get all distros on the same page here unless there's a compelling reason to diverge. Maybe the right answer is to get that configuration made by default in polkit upstream.
(In reply to comment #1) > any chance you could change openSUSE to have that meaning? I doubt so; but before I ask the right people, do you have any detail on what the wheel group can do compared to other groups on a Fedora system?
In Fedora, the wheel group is used for two purposes that I know of: 1) this in /etc/sudoers ## Allows people in group wheel to run all commands %wheel ALL=(ALL) ALL 2) This in the polkit configuration: [Configuration] AdminIdentities=unix-group:wheel [Wheel Group Permissions] Identity=unix-group:wheel Action=org.gnome.settingsdaemon.datetimemechanism.*;org.kde.kcontrol.kcmclock.save;org.freedesktop.RealtimeKit1.*;org.freedesktop.udisks.filesystem-mount-system-internal;org.freedesktop.hostname1.set-static-hostname ResultAny=auth_admin ResultInactive=auth_admin ResultActive=yes (basically replacing the desktop_admin_r roles previously used)
OK, this commit http://cgit.freedesktop.org/PolicyKit/commit/?id=763faf434b445c20ae9529100d3ef5290976d0c9 is for the 'wheel' part of this change. As noted in NEWS, see http://cgit.freedesktop.org/PolicyKit/commit/?id=8710055f9f3c8a4bd444210b86d7eea5a4a4f840 distributors who insist on being different can patch it out themselves. For the other part, e.g. [Wheel Group Permissions] Identity=unix-group:wheel Action=org.gnome.settingsdaemon.datetimemechanism.*;org.kde.kcontrol.kcmclock.save;org.freedesktop.RealtimeKit1.*;org.freedesktop.udisks.filesystem-mount-system-internal;org.freedesktop.hostname1.set-static-hostname ResultAny=auth_admin ResultInactive=auth_admin ResultActive=yes that gives extra powers to members in 'wheel', I'm not so sure about. I think the answer here is that the mechanisms should be more lenient and just use ResultActive=yes instead of insisting that authentication is needed even for mundane tasks ... after all, this is for users at the local console (of course, paranoid security-minded distros can lock down as they see fit). So for now I'm just going to nuke that stanza in the Fedora policy and if there are complaints about annoying authentication attempts, I'm just going to punt that to the Mechnanisms. As such, I consider this bug fixed.
Bah, sorry, comment 6 was intended for bug 41008. Please ignore. Sorry!
Vincent, did you ever get a chance to talk to the right people?
Wow, sorry for never coming back to you on this. But in short, no, I wasn't really able to change that in openSUSE back then :/ It's understandably a bit annoying, and I'm not sure how to properly deal with that. We probably want to know how other distros behave in that perspective. If it's just openSUSE, then maybe it's okay to ignore the issue, but if it affects more distro, then it's a different case...
we currently let the distribution choose the admin group, but not disable having an admin group. The latter is more complicated since it would require communicating to control-center about the lack of the feature and then disable parts of the UI at run time. I'm inclined to WONTFIX this bug for now unless other distros chime in, and we can get buy in from the control-center maintainers to make that change. closing, but anyone should feel free to reopen this bug if they want this decision to be reconsidered.
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.