No GUI way to add another user to be able to sudo

[Ryan Thiessen]

When installing Ubuntu the initial user is put into the /etc/sudoers file, which
is great. However there doesn't seem to be a way to add another user to this
file through the GUI -- only by using visudo which isn't very user friendly.

Possible solution:
There is already a group "sudo" on a default Ubuntu install, perhaps if you
added a line "%sudo ALL=(ALL) ALL" in the default install of /etc/sudoers, the
user could just add another account to the group "sudo" in the users GUI and
they would be able to use sudo as well.

[Phil Housley (undeconstructed)]

I think the reporter's suggestion makes a lot of sense here, as the ony other
change needed would be to add another "User Privilege" for "Gain adminstrator
privileges" or similar in users-admin.

[Matt Zimmerman (mdz)]

We agreed on IRC that this ought to happen for Hoary, which means it should
happen before feature freeze.

rcaskey said on IRC that he should be able to do the implementation and send
patches.

[Rob Caskey (rcaskey)]

Created an attachment (id=1284)
Adds a group called "admin" that can sudo and adds default user to it

I think this is right. First patch submitted, so I might have futzed something.
Any corrections very much appreciated. Left to do: change where passwd writes
to /etc/aliases so that it forwards to the group admin using a pipe to an as
yet unpackaged mail_group script. Figured I would leave that for someone more
"with it" concerning policy. Tgz contains two patches, one to add an admin
group and add admin to default sudoers and the second to add first user to
admin group.

[Rob Caskey (rcaskey)]

Created an attachment (id=1285)
Adds a group called "admin" that can sudo and adds default user to it

It would be good if there was a mail_group script packaged and hooked into the
dep chain so that the /etc/aliases file could pipe root's mail to it instead of
just to a single user. This is my first patch, so any advice/corrections
welcome!

[Jerome Haltom (wasabi)]

Why not the 'adm' group which already exists?

[Ryan Thiessen (mail-theantix)]

(In reply to comment #5)
> Why not the 'adm' group which already exists?

Why not what I originally suggested, the group that alread exists called "sudo"?
 It makes intuitive sense to me that the users allowed to sudo belong to the
"sudo" group, in fact that is the behaviour I expected to occur when I first
tried adding users to the sudo group in the first place.

[Colin Watson (cjwatson)]

(In reply to comment #5)
> Why not the 'adm' group which already exists?

That group already has a different meaning. Historically, it has been safe to
add users to the adm group because all they could do with it was read log files.
Allowing everyone in adm to gain root privilege would be a *significant*
escalation in their privilege; in my opinion, unsafe.

[Colin Watson (cjwatson)]

(In reply to comment #6)
> Why not what I originally suggested, the group that alread exists called "sudo"?
> It makes intuitive sense to me that the users allowed to sudo belong to the
> "sudo" group, in fact that is the behaviour I expected to occur when I first
> tried adding users to the sudo group in the first place.

That group already has a different meaning, which is not appropriate here:

       exempt_group
                   Users in this group are exempt from password and PATH
                   requirements. On Debian systems, this is set to the group
                   ’sudo’ by default.

We don't want to exempt all users from password requirements, and people may
already be using this group for its intended purpose so its semantics should not
be changed.

[Colin Watson (cjwatson)]

OK, we've discussed the group naming on #ubuntu-devel and decided that 'admin'
is probably the least bad name for the group. Most of the other obvious names
already have other assigned meanings, and as for the confusion with 'adm', it's
really adm that's misnamed and might one day be renamed. Also, 'admin' is the
naming used by OS X.

However, there are some problems with the current patch:

  * It claims gid 80 for itself. This is disallowed; base-passwd is the arbiter
of all gids in the 0-99 range, and base-passwd has never allocated a group
called 'admin' or a group with gid 80. Since a static gid isn't really needed, I
think sudo should just use addgroup --system and pick an arbitrary system gid.

  * sudo needs to complain if the admin group already exists, since the
administrator might already be using it for something else.

  * There should be a trailing newline in /etc/sudoers.

  * "create_default_suoders" typo. However, I think that function should just go
away entirely; it is no longer relevant, as passwd.config can just add the user
to the admin group and leave it at that. That code is essentially only used on
initial installation.

  * Adding the user to the admin group should be guarded by [ -z "$WANT_ROOT_PW" ].

Thanks a lot for the patch; I'm working on integrating it now, and fixing the
issues above at the same time. I should have this done before the Hoary feature
freeze deadline.

[Colin Watson (cjwatson)]

Actually, thinking about it, doing this in sudo.postinst at all is fraught with
problems. I propose a simpler solution: simply create the admin group in
passwd.config, and do away with all the changes to sudo. This allows us to do
nice things like omit the admin group from sudoers if a root password is set
(since in that case we don't add the initial user to sudoers, and there's a good
chance that the administrator doesn't want to use sudo to gain root privileges),
but more importantly it means that there's no chance that the admin group might
get created on upgrade and conflict with somebody's existing use of a group by
the same name.

I'm working on this now; the patch is smaller, which is often a good sign. :-)

[Colin Watson (cjwatson)]

Done:

shadow (1:4.0.3-30.7ubuntu8) hoary; urgency=low

  * Instead of adding the initial user to /etc/sudoers directly, create an
    'admin' group, add the initial user to that, and add %admin to
    /etc/sudoers. Based on a patch by Rob Caskey (closes: Ubuntu #1849).

 -- Colin Watson <email address hidden> Wed, 9 Feb 2005 01:59:28 +0000

One piece still remains, namely to add support for this in users-admin.
Reassigning to gnome-system-tools for that.

[Colin Watson (cjwatson)]

Note that this change deliberately only affects fresh installs, not upgrades.
The admin group will not be available on systems upgraded from Warty.

[Sivan Greenberg (sivan)]

(In reply to comment #11)
>
> One piece still remains, namely to add support for this in users-admin.
> Reassigning to gnome-system-tools for that.

I will check how to add it and do the neccessary changes.

[Sivan Greenberg (sivan)]

I think this deserves some more discussion, so the sane thing to do right now is:

 1) Have the install time created user be member of the admin group. (already
working)
 2) Add another group description to g-s-t's backend, to recognize the new group.
 3) Maybe make distinction now between the user profiles and create a nother
profile? and admin profile? or just use the current privileged
    profile (Desktop) to include membership of the admin group, thus allowing
users created with this profile to add new (other) users as admin
    members?

I'd appriciate some clarification and/or other comments and suggestions.

[Colin Watson (cjwatson)]

(In reply to comment #14)
> 3) Maybe make distinction now between the user profiles and create a nother
> profile? and admin profile? or just use the current privileged
> profile (Desktop) to include membership of the admin group, thus allowing
> users created with this profile to add new (other) users as admin
> members?

I don't really know users-admin, but for what it's worth I think "Desktop" is a
very bad name for something that lets you gain root privileges; could it be
something more like "Administrator"?

[Sivan Greenberg (sivan)]

(In reply to comment #15)
> (In reply to comment #14)
> > 3) Maybe make distinction now between the user profiles and create a nother
> > profile? and admin profile? or just use the current privileged
> > profile (Desktop) to include membership of the admin group, thus allowing
> > users created with this profile to add new (other) users as admin
> > members?
>
> I don't really know users-admin, but for what it's worth I think "Desktop" is a
> very bad name for something that lets you gain root privileges; could it be
> something more like "Administrator"?

Sure, so now we will have only two profiles, "unprivileged" and the
"Administrator" for creating new users , is that ok?

[Martin Pitt (pitti)]

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > 3) Maybe make distinction now between the user profiles and create a nother
> > > profile? and admin profile? or just use the current privileged
> > > profile (Desktop) to include membership of the admin group, thus allowing
> > > users created with this profile to add new (other) users as admin
> > > members?
> >
> > I don't really know users-admin, but for what it's worth I think "Desktop" is a
> > very bad name for something that lets you gain root privileges; could it be
> > something more like "Administrator"?
>
> Sure, so now we will have only two profiles, "unprivileged" and the
> "Administrator" for creating new users , is that ok?

Please create three profiles: the already existing "Unprivileged" (no groups)
and "Desktop" (audio, plugdev and stuff, but not admin), and an additional group
"Administrator" which has the Desktop groups + group admin.

[Rob Caskey (rcaskey)]

(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > (In reply to comment #14)
> > > > 3) Maybe make distinction now between the user profiles and create a nother
> > > > profile? and admin profile? or just use the current privileged
> > > > profile (Desktop) to include membership of the admin group, thus allowing
> > > > users created with this profile to add new (other) users as admin
> > > > members?
> > >
> > > I don't really know users-admin, but for what it's worth I think "Desktop" is a
> > > very bad name for something that lets you gain root privileges; could it be
> > > something more like "Administrator"?
> >
> > Sure, so now we will have only two profiles, "unprivileged" and the
> > "Administrator" for creating new users , is that ok?
>
> Please create three profiles: the already existing "Unprivileged" (no groups)
> and "Desktop" (audio, plugdev and stuff, but not admin), and an additional group
> "Administrator" which has the Desktop groups + group admin.
>
>
>
How about a change in terminology?

Unprivileged -> Remote User
Desktop -> Normal User
Administrator -> fine as it is

Most Ubuntu systems probably won't have any unpriveleged users, so perhaps that should be left? Anyone who needs an unpriveleged
user probably knows how to create one or set up a template to do so.

--Rob

[Sivan Greenberg (sivan)]

Created an attachment (id=1373)
patch for users-conf backend to recognize the new admin groupr and make it
possible to make new user a member of it

[Sivan Greenberg (sivan)]

(In reply to comment #19)
> Created an attachment (id=1373) [edit]
> patch for users-conf backend to recognize the new admin groupr and make it
> possible to make new user a member of it
>

Uploaded:

 * system-tools-backends (1.1.91-0ubuntu4) hoary; urgency=low