I'm for this in general, but I strongly suggest uncommenting the 

%wheel	ALL=(ALL)	ALL

line and using that rather than machine-editing the sudoers file, which has a complicated and fragile syntax. Then we can just add and remove users to and from the group using already-existing tools.

I'd suggest we not add users "magically", but instead have a checkbox in the firstboot user-creation dialog and a corresponding one in system-config-users.
We've been doing this exact thing in BU Linux for six or seven years and it's been very successful. I can even dig out our patch for system-config-users if it'd be helpful (there's also some BU-specific stuff in there).

Using the wheel group approach has another big advantage: if we add the line "UGROUPS=wheel" to /etc/security/console.apps/config-util, this brings auth-as-admin-user functionality to the various config tools which have not yet been ported to do it The Right Way via PolicyKit.

(In reply to comment #1)
> I'm for this in general, but I strongly suggest uncommenting the 
> 
> %wheel ALL=(ALL) ALL
> 
> line and using that rather than machine-editing the sudoers file

Seconded.  But I think that would be better done directly in the sudo package instead of firstboot - Cc'ing sudo maintainer.

(In reply to comment #2)
> (In reply to comment #1)
> > I'm for this in general, but I strongly suggest uncommenting the 
> > 
> > %wheel ALL=(ALL) ALL
> > 
> > line and using that rather than machine-editing the sudoers file
> 
> Seconded.  But I think that would be better done directly in the sudo package
> instead of firstboot - Cc'ing sudo maintainer.

It can't be done, without firstboot implementing something, the purpose of the bug is to make sudo useful by default when installed, as there is no human users when sudo is first installed by Anaconda such a process can not be done by sudo.

It has to have some action by firstboot (either editing sudoers, or adding to wheel group), a sub-task of implementing the latter is by default shipping sudo with the wheel group enabled (not the primary task).

I was going to write about how I'm not keen on using the wheel group thing, but then I just remembered that...

By enabling the wheel group by default (it brings back memories to when I used cPanel - ekkk!), it means we can provide the LiveCD/DVDs with sudo enabled as well.  This would allow us to change from su -c in our documentation, to sudo.  But as said before, for it to be useful in standard setups, it must have some level of implementation at firstboot and the add user scripts/programs. (sudo in LiveCD/DVD is just a nice to have)

> Seconded.  But I think that would be better done directly in the sudo package
> instead of firstboot - Cc'ing sudo maintainer.

Sorry, I was unclear. Yes, the first change is to uncomment the group line in the default sudoers file. The second change is to make the end-user tools (minimally firstboot, but probably also system-config-users) have an easy "this user is an admin" checkbox.

hey, this would be a nice thing to have. Unfortunately I'm not sure using the wheel group is OK. There is a possible security risk, when you start using LDAP/NIS later. Any user in wheel group from there will get access to root on client machine.

Looking at my sudoers, I see :)
user         ALL=(ALL)       ALL

Yes, the change needs to be documented so that anyone using wheel for another purpose is aware.

It's a longstanding tradition that the wheel group is reserved for admin users, so I think it's the best one to choose. Anything else is more likely to conflict with some random existing practice somewhere.

Using LDAP/NIS isn't a particular added risk here -- if someone can manipulate groups, they can probably add themselves to the "root" group already.

(In reply to comment #6)

> Using LDAP/NIS isn't a particular added risk here -- if someone can manipulate
> groups, they can probably add themselves to the "root" group already.

I can't agree. Try
$ sudo find / -mount -group root -perm /020 -type f
Even if you have root group you  don't have such a chance to modify things.

What about this solution:
Lets use %wheel group, but implement mechanism that will filter certain groups(wheel) from remote account dtb(LDAP/NIS). To be more concrete - option in /etc/nsswith.conf.

Hmmm, looks like the erlang package needs fixing. :)

But what if instead of 'root' I join polkituser?

I'll concede that it's a possible added risk, so having an option that does that filtering would be good. It'd need to be easily configurable, though, because many places want the ability to delegate this centrally.

+1 to RFE from a Fedora Documentation perspective.

Having to document with 'su -c' is a PITA.

Having to have readers setup 'sudo' in each document is a PITA.

Common practice in other tutorials is to use 'sudo', and we cannot build on that experience with 'su -c'.

Finally, in terms of security problems, having to use 'su' as the only default option, thus requiring knowing the root password, is also a big issue.

With a smart 'sudo' enabling scheme, our documentation efforts are going to be reduced overall by at least 10%.  That's pretty huge.

Did we miss out on this improvement for Fedora 11?  Should we have driven this as a feature?

*** Bug 489284 has been marked as a duplicate of this bug. ***

FWIW, it would be useful for PolicyKit as well, as it means that, instead of being asked for an administrator password, the user would actually be asked for their own password.

It would be nice to drive this as a feature for F13. I think we should change the subject from being sudo-specific to "Configure selected user-accounts to perform typical admin tasks with auth-as-self". Or something like that, but more concise.

On the other side of the problem:

It may be reasonable to consider allowing sudo for any command _too_ lax for this.

There's also two other important privilege-escalation mechanisms to be considered:

Legacy consolekit can be configured to give members of a given group auth-as-self behavior by setting UGROUPS=wheel (or whatever) in the corresponding config file. And fortunately, most system-config-foo utilities now include /etc/security/console.apps/config-util, so putting UGROUPS=wheel there is 90% of the issue.

PolicyKit can easily implement this too, by setting ResultAny=auth_self_keep.
But while, pkla files can use wildcards, I don't think they can include other files. That may be somewhat inconvenient.

*** Bug 566843 has been marked as a duplicate of this bug. ***

Hi, new firstboot has an option to run system-config-users to create the new user, even more of them, with an Advanced button, so if the user uses system-config-users to create new users, it would be hard for firstboot to check which users he created, which one was first, and setup the sudoers file accordingly.

In the future I would like to just import some system-config-users widget and put it in the firstboot window, so I guess it would be better to add this "add user to sudoers" feature to system-config-users, rather than to firstboot.

I don't want to make firstboot into some complicated user creating tool with the ability to set up every different aspect of the new user account.
In my perfect world, firstboot should be just a convenient way of presenting some of the nice and cool config tools we have in a particular order, so the user does not have to run them by himself, especially if he doesn't know they exist at all.

> Hi, new firstboot has an option to run system-config-users to create the new
> user, even more of them, with an Advanced button, so if the user uses
> system-config-users to create new users, it would be hard for firstboot to
> check which users he created, which one was first, and setup the sudoers file
> accordingly.

"First user = admin" isn't necessarily a good model anyway.

I think a better model still is the wheel group, and system-config-users can be given a special more-visible interface for administrative access.

That's what BU Linux has done for a decade, as mentioned back in comment #1. :)

wheel_group++ still from me too, FWIW.

OK, but the uncommenting of the wheel line should be done in sudo package, then firstboot can just have a checkbox "add to wheel" and it will add the newly created user to wheel group. This is how you want it?

(In reply to comment #19)
> OK, but the uncommenting of the wheel line should be done in sudo package, then
> firstboot can just have a checkbox "add to wheel" and it will add the newly
> created user to wheel group. This is how you want it?    

Yes. Although "add to wheel" isn't exactly how it should be worded.

Yes, I agree with that, it was just an example. So what text will we put there?

OK so, I added a checkox with text "Add user to Administrators group" to firstboot, which if checked, will make the newly created user a member of wheel group. So now all that needs to be done is uncommenting of the wheel line in sudo config file, and that should be done by sudo maintainers.

Is there a sudo bug, then?

(I mean has one been opened)

I would go for the solution using "%group ALL=(ALL) ALL" in sudoers, but I don't think that using the wheel group for this is good because this group already exists for some time and some people might be using it (and users in this group would suddenly get full root access via sudo).

What about a completely new group, perhaps added by the sudo package? (e.g. sudoroot in /etc/groups and "%sudoroot ALL=(ALL) ALL" in /etc/sudoers)

I have nothing against the solution with a new special group.

I very strongly believe that we should use the existing wheel group rather than making up something new and arbitrary. This group is historically used for the express purpose of giving people root access. And in fact, that is strongly encouraged by the long-standing commented-out example %wheel entry in the upstream sudoers file (including what we ship). If you do a quick search for "wheel group", you'll find tons of documentation suggesting that people use that group for this purpose. By picking something else, we're likely to force *more* people to change their configurations (and behavior), and we become less cross-distribution sane.

I agree that we shouldn't spring it on people mid-release or anything, but it seems fine to address any possible misuses with a prominent entry in the release notes.

I wholeheartedly second Matthew's comment 27.  And FWIW there is also a wheel example in /etc/pam.d/su.

I created a sudo bug for this #656873

Bug #656873 (linked)

(In reply to comment #29)
> I created a sudo bug for this #656873

We probably also want something similar for pam -- add "UGROUPS=wheel" to /etc/security/console.apps/config-util, and for any appropriate usermode-enabled apps which don't have that already.

Also, for polkit -- 

  Identity=unix-group:wheel
  ResultAny=auth_self

for the appropriate utils.

So the firstboot part is done, can I close this bug now?

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.