Move "admin" group to "sudo"

Status changed to 'Confirmed' because the bug affects multiple users.

Thanks for your report. I can confirm this by trying to unlock the settings in 'Time & Date' or 'Users account'
Setting to Critical because a user cannot to any administrative task on a default installation without manually adding the user to the admin group.

This appears to be deliberate. Here's Steve's changelog:

    - Don't set up the admin group or add the user to it; the sudo package
      now always sets up the sudo group on install, so we can as well use
      this group as the admin group. This will be inconsistent with
      previous Ubuntu releases, but consistent with Debian and compatible
      with sudo.

I think, for compatibility, policykit-1's configuration should allow both the admin and sudo groups.

Fixed in Debian packaging git.

This bug was fixed in the package policykit-1 - 0.102-2

---------------
policykit-1 (0.102-2) unstable; urgency=low

  * 02_gettext.patch: Explicitly #include <locale.h> to fix non-optimized
    build. Thanks Ivan Krasilnikov for pointing this out.
  * debian/rules: When building on Ubuntu, also consider the "sudo" group as
    administrator, for compatibility with Debian and sudo itself. Keep "admin"
    for existing systems. (LP: #893842)
  * Convert to Multi-Arch and dh compat 9. Thanks Daniel Schaal for the
    patch! (Closes: #636196)
 -- Martin Pitt <email address hidden> Fri, 25 Nov 2011 07:44:09 +0100

This bug was fixed in the package policykit-desktop-privileges - 0.10

---------------
policykit-desktop-privileges (0.10) precise; urgency=low

  * Group "sudo" is the new "admin", allow both. (LP: #893842)
  * debian/control: Fix overly long line.
  * debian/control: Add recently added privileges to description.
  * debian/control: Bump Standards-Version to 3.9.2, no changes necessary.
 -- Martin Pitt <email address hidden> Fri, 25 Nov 2011 08:03:49 +0100

This bug was fixed in the package accountsservice - 0.6.15-2

---------------
accountsservice (0.6.15-2) unstable; urgency=low

  [ Gunnar Hjalmarsson ]
  * 0009-language-tools.patch: Sort the list of language options, for the
    language chooser in LightDM (LP: #868346).

  [ Martin Pitt ]
  * 0002-create-and-manage-groups-like-on-a-ubuntu-system.patch: Use "sudo"
    group instead of "admin", for Debian/sudo compatibility. However, keep
    recognizing "admin" as administrator, too. (LP: #893842)
 -- Martin Pitt <email address hidden> Fri, 25 Nov 2011 08:28:18 +0100

Seems to work out ok, will try a fresh image when this fix is in it.

(user accounts may look 'odd' to people when they see their previously known as "Administrator" now as "Standard" or if creating an add. 'Administrator' user account getting a choice in the various auth popups

jockey postinst fixed in bzr.

For the record, the change in comment 4 applied to the "user-setup" package.

This bug was fixed in the package jockey - 0.9.5-0ubuntu5

---------------
jockey (0.9.5-0ubuntu5) precise; urgency=low

  * debian/jockey-common.postinst: Move from group "admin" to "sudo".
    (LP: #893842)
 -- Martin Pitt <email address hidden> Fri, 25 Nov 2011 08:52:38 +0100

This bug was fixed in the package userconfig - 0.9.0-0ubuntu10

---------------
userconfig (0.9.0-0ubuntu10) precise; urgency=low

  * In debian-changes-0.9.0-0ubuntu5 update admin user to sudo, LP:
    #893842
 -- Jonathan Riddell <email address hidden> Fri, 25 Nov 2011 13:12:17 +0000

Affects language-selector on a fresh Precise installation.

Traceback (most recent call last):
  File "/usr/bin/gnome-language-selector", line 27, in <module>
    options=options)
  File "/usr/lib/python2.7/dist-packages/LanguageSelector/gtk/GtkLanguageSelector.py", line 141, in __init__
    grp.getgrnam("admin")[2] in os.getgroups())
KeyError: 'getgrnam(): name not found: admin'

This bug was fixed in the package language-selector - 0.59

---------------
language-selector (0.59) precise; urgency=low

  * LanguageSelector/gtk/GtkLanguageSelector.py: Fix crash if "admin" group
    does not exist, and also look for membership of "sudo". (LP: #893842)
 -- Martin Pitt <email address hidden> Tue, 29 Nov 2011 14:56:22 +0100

@ Jean-Baptiste Lallement,

I'm curious what problems to look for and just how to reproduce the problem.

Does this also effect the creation of a new user account?

Sorry if I'm just being stupid, but I'm just a simple minded end user :^)

As always, thanks for all you do.

The GNOEM language selector is completely broken on the current image. No need to reproduce or provide further info. I already uploaded the fix, we'll spin another alpha-1 candiate soon.

Thanks Martin.

command-not-found also needs a fix. From bug 910481 :

===
To test -
As an admin user run a command for something not installed, the message will be -
To run 'whatever' please ask your administrator to install the package 'whatever'

What should be shown -
The program 'whatever' is currently not installed. You can install it by typing:
sudo apt-get install 'whatever'

confirmed by adding myself back to 'admin' group, then the latter message is shown
===

This bug was fixed in the package command-not-found - 0.2.44.1ubuntu3

---------------
command-not-found (0.2.44.1ubuntu3) precise; urgency=low

  * Recognize the 'sudo' group as a valid admin group as well, so that we
    return the correct error message for those with admin access.
    LP: #893842.
 -- Steve Langasek <email address hidden> Mon, 02 Jan 2012 14:47:43 -0800

"This bug was fixed in the package command-not-found - 0.2.44.1ubuntu3"
Sorry to say that on a fresh install with 1/08 image this isn't fixed, using 0.2.45ubuntu2 & also trying 0.2.44.1ubuntu3

Can also be seen on a live session with the ubuntu user, same deal, only the admin group gets proper 'command not found' prompt

confirmed here in testing. reopening.

This bug was fixed in the package command-not-found - 0.2.45ubuntu3

---------------
command-not-found (0.2.45ubuntu3) precise; urgency=low

  * Use the right group name ('sudo', not 'sudoers'). LP: #893842.
 -- Steve Langasek <email address hidden> Thu, 12 Jan 2012 14:21:01 +0100

As far as the new command-not-found - in a current 12.04 install still not working with the upgrade. Tried a purge & install, same thing, still getting the 'ask administrator ...'
(maybe all would be well of a new image that has the upgraded package?

So went ahead & edited the script simply changing the order, ie. -- lines 118-119

 try:
            self.user_can_sudo = grp.getgrnam("sudo")[2] in posix.getgroups() or grp.getgrnam("admin")[2] in posix.getgroups()

Then works as expected, attached terminal progression to show

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/893842

command-not-found still not working as intended. As previously mentioned if you reverse the ordering then it does work (at least in the normal case where the 'Admin' user is only in the sudo group

@Doug - I've tried recreating this multiple times on different precise systems, that have been upgraded from feisyt and natty (or so), without any luck. Could you possibly test this again? Thanks in advance.

I can confirm that command-not-found 0.2.46ubuntu2 on my precise system (clean install) is still broken.
The problem is this line::
self.user_can_sudo = grp.getgrnam("admin")[2] in posix.getgroups() or grp.getgrnam("sudo")[2] in posix.getgroups()
on clean systems there is no admin group, so first grp.getgrnam("admin") raises KeyError which is then catched and self.user_can_sude is set to False without checking if user is in sudo group.
As mentioned by mc3man in #24 changing the order of grp.getgrnam will fix that because sudo group is always there (and if user is not part of it, admin group will be checked)

I've confirmed this on a Live CD now.

This bug was fixed in the package command-not-found - 0.2.46ubuntu3

---------------
command-not-found (0.2.46ubuntu3) precise; urgency=low

  * Check for the always-present sudo group first, so that checking for
    'admin' on new installs doesn't raise a key error by mistake.
    LP: #893842.
 -- Steve Langasek <email address hidden> Thu, 09 Feb 2012 14:46:59 -0800

This bug also affects update-notifier 0.118.1ubuntu1 in precise. It's hard-coded to only launch for members of the admin group. Since there's no admin group in precise, it bails and launches for all users. The problem code is in the in_admin_group() function in update-notifier.c. I'm not sure if it makes more sense to just change this completely from admin to sudo or to check for either group.

This bug was fixed in the package update-notifier - 0.119ubuntu1

---------------
update-notifier (0.119ubuntu1) precise; urgency=low

  * src/update-notifier.c: Consider both the "sudo" and "admin" groups as
    administrator. (LP: #893842)
 -- Martin Pitt <email address hidden> Sun, 11 Mar 2012 10:29:28 +0100

indicator-cpufreq is affected as well. Working as intended with this little patch, please sponsor the upload.

This change is in the current release notes.

Thanks Artem! Sponsored.

This bug was fixed in the package indicator-cpufreq - 0.1.4-0ubuntu2

---------------
indicator-cpufreq (0.1.4-0ubuntu2) precise; urgency=low

  * Allow both "sudo" and "admin" groups to change CPU frequency
    to prevent needless password prompts (LP: #893842).
 -- Artem Popov <email address hidden> Wed, 28 Mar 2012 12:18:50 +0700

Another instance of this in gnome-menus, will fix.

gnome-menus is fine after all, the "admin" check patch is disabled.