Bug 462161 - RFE: Setup sudoers file during user creation step
RFE: Setup sudoers file during user creation step
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: firstboot (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Martin Gracik
Fedora Extras Quality Assurance
: FutureFeature
: 489284 566843 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-13 02:04 EDT by Nigel Jones
Modified: 2013-07-04 08:46 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 06:20:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nigel Jones 2008-09-13 02:04:37 EDT
Something that 'would be nice' would be to configure /etc/sudoers by default when the first user is added.

I realize it is late in the Fedora 10 cycle, so I don't expect it to be implemented for this release, if it is, my suggestion would be:

Add a checkbox into the advanced options dialog box, that adds the following to the sudoers file:

<username>	ALL=(ALL)	ALL

Which would allow the first user to sudo from the word go.

For Fedora 11 onwards I'd suggest it to be automatically done, with the following criteria:

The entry is only added if:
* The user has selected a shadow/passwd based login mechanism (i.e. no LDAP/NIS/etc)
* The user added is the first non system user (there may be cases where a standard user has been added in %post of a kickstart I'd imagine
* The user has not specifically requested that the sudoers file not be altered (in advanced options)

Main motivation for doing this is to kind of lead us away from the root focused way of doing things, it'd enable us to focus on users been enabled to preform such tasks, not having to remember another credential to do a task.
Comment 1 Matthew Miller 2008-09-17 11:23:07 EDT
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.
Comment 2 Ville Skyttä 2008-09-20 08:14:22 EDT
(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.
Comment 3 Nigel Jones 2008-09-20 08:26:33 EDT
(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)
Comment 4 Matthew Miller 2008-09-20 08:35:32 EDT
> 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.
Comment 5 Peter Vrabec 2008-09-22 07:50:46 EDT
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
Comment 6 Matthew Miller 2008-09-22 10:12:37 EDT
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.
Comment 7 Peter Vrabec 2008-09-23 04:11:13 EDT
(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.
Comment 9 Matthew Miller 2008-09-23 09:36:18 EDT
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.
Comment 10 Karsten Wade 2008-09-24 10:50:59 EDT
+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.
Comment 11 Karsten Wade 2009-02-05 14:21:11 EST
Did we miss out on this improvement for Fedora 11?  Should we have driven this as a feature?
Comment 12 Chris Lumens 2009-03-09 10:12:41 EDT
*** Bug 489284 has been marked as a duplicate of this bug. ***
Comment 13 Bastien Nocera 2009-06-16 07:00:16 EDT
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.
Comment 14 Matthew Miller 2009-11-25 15:48:21 EST
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.
Comment 15 Christopher Beland 2010-03-12 11:02:23 EST
*** Bug 566843 has been marked as a duplicate of this bug. ***
Comment 16 Martin Gracik 2010-07-21 08:43:42 EDT
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.
Comment 17 Matthew Miller 2010-07-21 08:56:43 EDT
> 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. :)
Comment 18 Ville Skyttä 2010-07-21 11:27:17 EDT
wheel_group++ still from me too, FWIW.
Comment 19 Martin Gracik 2010-07-22 04:28:28 EDT
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?
Comment 20 Matthew Miller 2010-07-22 07:30:42 EDT
(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.
Comment 21 Martin Gracik 2010-07-22 09:24:19 EDT
Yes, I agree with that, it was just an example. So what text will we put there?
Comment 22 Martin Gracik 2010-11-10 09:58:22 EST
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.
Comment 23 Jon Masters 2010-11-18 03:15:20 EST
Is there a sudo bug, then?
Comment 24 Jon Masters 2010-11-18 03:15:46 EST
(I mean has one been opened)
Comment 25 Daniel Kopeček 2010-11-23 05:27:20 EST
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)
Comment 26 Martin Gracik 2010-11-23 07:06:11 EST
I have nothing against the solution with a new special group.
Comment 27 Matthew Miller 2010-11-23 07:42:35 EST
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.
Comment 28 Ville Skyttä 2010-11-23 10:40:05 EST
I wholeheartedly second Matthew's comment 27.  And FWIW there is also a wheel example in /etc/pam.d/su.
Comment 29 Martin Gracik 2010-11-24 07:46:24 EST
I created a sudo bug for this #656873
Comment 30 Matthew Miller 2010-11-24 08:32:40 EST
Bug #656873 (linked)
Comment 31 Matthew Miller 2010-11-24 12:00:38 EST
(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.
Comment 32 Martin Gracik 2011-01-18 08:20:25 EST
So the firstboot part is done, can I close this bug now?
Comment 33 Fedora Admin XMLRPC Client 2011-02-16 10:49:10 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 34 Fedora Admin XMLRPC Client 2011-02-16 11:09:14 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Note You need to log in before you can comment on or make changes to this bug.