Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 86188 - RFE: provide sudo-like mechanism whereby members of certain groups can auth with their *own* passwords [has patch]
Summary: RFE: provide sudo-like mechanism whereby members of certain groups can auth w...
Alias: None
Product: Fedora
Classification: Fedora
Component: usermode
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact:
: 81255 (view as bug list)
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
Reported: 2003-03-16 18:12 UTC by Matthew Miller
Modified: 2013-07-02 22:58 UTC (History)
8 users (show)

Fixed In Version: 1.74-1
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2007-06-19 14:35:53 UTC

Attachments (Terms of Use)
adds UGROUP to userhelper variables (deleted)
2003-03-18 21:36 UTC, Matthew Miller
no flags Details | Diff
better implementation of UGROUP (deleted)
2003-03-18 22:19 UTC, Matthew Miller
no flags Details | Diff
update for 1.67; change UGROUP to UGROUPS (deleted)
2003-04-09 19:07 UTC, Matthew Miller
no flags Details | Diff
"feature complete" version allows multiple UGROUPS (deleted)
2003-05-03 21:16 UTC, Matthew Miller
no flags Details | Diff
updated for 1.69-3 (deleted)
2004-01-22 22:46 UTC, Matthew Miller
no flags Details | Diff
patch to userhelper man page (deleted)
2004-04-02 19:27 UTC, Matthew Miller
no flags Details | Diff
updated for 1.70-6 (deleted)
2004-07-10 16:40 UTC, Matthew Miller
no flags Details | Diff

Description Matthew Miller 2003-03-16 18:12:12 UTC
Currently, applications like redhat-config-users prompt for the root password
when executed by a non-root user. It would be very nice if power could be
delegated more specifically, so that certain users could run certain
administrative commands without knowing the root password. However, it's good to
have some level of authentication -- these users should be prompted for their
own passwords. (This is similar to the behavior of the sudo command.)

I'd suggest that the security/console.apps/whatever files should have a new
parameter where one could list groups whose members are allowed to execute the
given command in this manner. ("wheel" might be a popular choice, but more
specific ones could also exist.) I suppose it's probably also reasonable to
allow individual users to be listed in these files, but that seems like it might
be a maintenance hassle.

Currently, one can manipulate the pam modules to allow members of a group to
execute given commands, but there's no (obvious to me, at least) mechanism for
prompting for the user's own password. I don't think this would be too hard to
add, and it'd be extremely useful.

Comment 1 Matthew Miller 2003-03-18 21:36:33 UTC
Created attachment 90653 [details]
adds UGROUP to userhelper variables

This is a simple attempt to introduce the requested feature. It adds a UGROUP
variable to userhelper (for /etc/security/console.apps/foo files). When this is
not set, behavior is exactly as before. When it is set, and when USER is unset
or <user>, attempt to authenticate as invoking user for members of UGROUP, but
require root password for everyone else.

Comment 2 Matthew Miller 2003-03-18 21:37:41 UTC
(I realize that there's no way this is going in the upcoming RHL release. But I
hope it or something like it will be considered for the next time around.)

Comment 3 Matthew Miller 2003-03-18 21:45:30 UTC
Idea for alternate semantics: if UGROUP is set, any member of that group could
authenticate as themselves, and people not members of that group would fall back
to authenticating as USER. If USER is set to <user>, UGROUP would effectively be
redundant. There should also be a <none> special value for USER, which would
mean that non-UGROUP members would always just be denied. 

I think I like that better; I'll work on that for a next patch.

It'd also be nice to allow multiple groups, of course.

Comment 4 Matthew Miller 2003-03-18 22:19:16 UTC
Created attachment 90654 [details]
better implementation of UGROUP

Ok, yeah. This version does as explained above:

1) if UGROUP is not set, same behavior as always

2) if UGROUP *is* set, members of that group can authenticate as themselves
regardless of USER setting. (Non-members still use USER.)

3) new <none> value for USER denies access; when used in conjunction with
UGROUP, only members of the given group can authorize at all and others are
given an Insufficient Rights message.

Sorry for the quick succession of bugzilla spam. This version should be good
for a while. :)

Comment 5 Matthew Miller 2003-04-09 19:07:16 UTC
Created attachment 91044 [details]
update for 1.67; change UGROUP to UGROUPS

This version updates the patch to apply cleanly to 1.67 (minor change) and
changes UGROUP to UGROUPS, in anticipation of future work to enable a list of

Right now, the changes are extrememly minimal:

$ diffstat usermode-1.67-sudoish.patch
 userhelper-wrap.c |	3 ++-
 userhelper.c	   |   26 +++++++++++++++++++++++++-
 2 files changed, 27 insertions(+), 2 deletions(-)

And 17 of the added lines are to add a simple function to check if a given user
is a member of a given group, and two of the others are comments, so it's
basically an 8 line change. Changing to allow a list of groups will be be a bit
more complicated, but I think useful enough to warrant it. So I'm changing the
name to UGROUPS now, because we're updating all of the redhat-config- programs,
and I don't want to do that twice. :)

Comment 6 Chris Ricker 2003-04-09 20:12:01 UTC
I still think fixing Bug 81255 is a more generic solution which would allow the
same result

Comment 7 Matthew Miller 2003-04-09 20:32:56 UTC
Chris -- I can't think of a way to make the bug #81255 pam_listfile solution
allow authentication-as-self, which is a key feature here. Am I missing something?

Comment 8 Matthew Miller 2003-05-03 21:16:58 UTC
Created attachment 91488 [details]
"feature complete" version allows multiple UGROUPS

Okay, I stopped being a slacker and added the code necessary to allow UGROUPS
to be a comma-separated list of groups. (With whitespace trimmed, too.)

I'm not really happy with "UGROUPS" as the variable name -- it's not
descriptive enough. AUTHASUSERGROUPS seems a bit too long, and AAUGROUPS is
just adding vowels to the beginning without really adding extra information. :)
Suggestions welcome.

Comment 9 Matthew Miller 2003-05-07 02:15:21 UTC
Patch works unchanged on 1.68 from rawhide.

Comment 10 Matthew Miller 2004-01-22 22:46:46 UTC
Created attachment 97199 [details]
updated for 1.69-3

Updated patch for package in fedora devel tree. Tested and works rebuilt on RHL

The patch doesn't touch any of the SELinux stuff; not sure if it needs to or
how that would/should interact.

Comment 11 Matthew Miller 2004-02-10 20:15:26 UTC
Continuing conversation with myself.... Patch applies cleanly to
1.69-4; haven't tested extensively. I'll do that when Fedora Core 2 is

Still looking for suggestions for a better term than "UGROUPS".

Comment 12 Matthew Miller 2004-04-02 19:27:24 UTC
Created attachment 99080 [details]
patch to userhelper man page

Adds documentation for UGROUPS and USER=<none> features to the man page for

Comment 13 Matthew Miller 2004-04-02 19:28:50 UTC
Patch applies cleanly to 1.69-5 as well. I'm still not sure about how
all this will integrate with SE Linux -- I posted to the
fedora-selinux mailing list, but haven't gotten any feedback yet.

Comment 14 Matthew Miller 2004-04-08 17:19:11 UTC
patch applies cleanly to 1.70-2.

Comment 15 Matthew Miller 2004-04-15 20:35:42 UTC
Any chance of getting this in before the test3 devel freeze? It's very
nice. And it's change with minimal impact if not enabled explicitly
(by editing the console.apps files).

Comment 16 Matthew Miller 2004-07-05 14:46:38 UTC
Please consider for Fedora Core 3. Thanks.

Comment 17 Alan Cox 2004-07-10 14:49:50 UTC
Looks sensible but doesn't apply to CVS head btw

Comment 18 Matthew Miller 2004-07-10 16:40:28 UTC
Created attachment 101780 [details]
updated for 1.70-6

Looks like 'ruid_user' changed to 'invoking_user'. This version works with
1.70-6 in rawhide, and I assume CVS.

Comment 19 Matthew Miller 2004-07-10 16:49:32 UTC
PS: the changelog for usermode says:

  * Tue Jul 1 2004 Dan Walsh <> 1.70-5
  - Fix to use root if user not defined

but my patch is touching the part of the code where that selection
seems like it would logically be made (so when I read the changes, I
thought that might be the conflict) but it is unchanged -- in
get_user_for_auth() in userhelper.c:

   configured_user = svGetValue(s, "USER");
   if (configured_user == NULL) {
       ret = invoking_user;
   } else
so if USER isn't defined, it seems like it would still default to
<user>. (And in fact, on testing, it that's what it does.)

Comment 20 Havoc Pennington 2004-09-14 21:02:32 UTC
Putting on target tracking bug, since I think we should target at
least commenting on this patch.

Comment 21 Matthew Miller 2004-10-14 17:49:51 UTC
Note -- patch for 1.70-6 applies fine to 1.73-1 in rawhide, but I
haven't tested it thouroughly yet.

Comment 22 Jindrich Novy 2004-10-15 08:40:33 UTC
Hi Mathew,

thank you for the patch and for talking for such a long time with
yourself here. I like the idea behind the patch that the users needed
to authenticate will not be prompted for the root but their own
password. In that manner I think that the solution presented here
seems better to me that in Bug 81255 presented by Chris.

Dan, is there something wrong with the patch from the SELinux point of

Comment 23 Daniel Walsh 2004-10-15 17:38:13 UTC
This looks ok to me.  We pulled most of the special USERNAME handling
out of userhelper, and only left the transition stuff in it.  We had
the machine prompting for Username a while back but changed it back
for targeted policy reasons.  I suspect this is opening potential
security holes though.   One being that if you are using NISGroups you
could be fooled into allowing access with user password, secondly if I
only allow 
say system-config-printer to have this functionality, pam_timestamp
will still allow the users to startup other apps for the X Minutes
that it is   in effect.


Comment 24 Daniel Walsh 2004-10-15 18:36:39 UTC
Ok after talking to Nalin, he told me that pam_stimestamp will not be
a problem since it records if you logged in using your password or
roots.  The second problem also exists for sudo, so I guess we open no
more of a security hole than already exists.


Comment 25 Jindrich Novy 2004-10-20 08:43:24 UTC
The patches are now applied to usermode upstream CVS.

Mathew, thanks for them!

Comment 26 Jindrich Novy 2004-10-20 08:52:22 UTC
*** Bug 81255 has been marked as a duplicate of this bug. ***

Comment 27 Matthew Miller 2004-10-20 13:17:58 UTC
Cool, thanks!

Comment 28 Christopher Brown 2007-06-19 14:26:01 UTC

Re-opening this bug as discussed in:

Currently users need to be added to wheel post-install. Can this be done through
choice or by default during install as I find this feature very useful.

Can it be implemented for Fedora 8?

Comment 29 Matthew Miller 2007-06-19 14:35:53 UTC
This bug should be left closed -- it's about getting the infrastructure in place. 

Implementing a configuration based on a given policy should get its own new bug.

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