Bug 86188 - RFE: provide sudo-like mechanism whereby members of certain groups can auth with their *own* passwords [has patch]
RFE: provide sudo-like mechanism whereby members of certain groups can auth w...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: usermode (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jindrich Novy
: FutureFeature, Reopened
: 81255 (view as bug list)
Depends On:
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2003-03-16 13:12 EST by Matthew Miller
Modified: 2013-07-02 18:58 EDT (History)
8 users (show)

See Also:
Fixed In Version: 1.74-1
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-19 10:35:53 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)
adds UGROUP to userhelper variables (2.15 KB, patch)
2003-03-18 16:36 EST, Matthew Miller
no flags Details | Diff
better implementation of UGROUP (2.35 KB, patch)
2003-03-18 17:19 EST, Matthew Miller
no flags Details | Diff
update for 1.67; change UGROUP to UGROUPS (2.37 KB, patch)
2003-04-09 15:07 EDT, Matthew Miller
no flags Details | Diff
"feature complete" version allows multiple UGROUPS (2.86 KB, patch)
2003-05-03 17:16 EDT, Matthew Miller
no flags Details | Diff
updated for 1.69-3 (3.06 KB, patch)
2004-01-22 17:46 EST, Matthew Miller
no flags Details | Diff
patch to userhelper man page (1.27 KB, patch)
2004-04-02 14:27 EST, Matthew Miller
no flags Details | Diff
updated for 1.70-6 (3.05 KB, patch)
2004-07-10 12:40 EDT, Matthew Miller
no flags Details | Diff

  None (edit)
Description Matthew Miller 2003-03-16 13:12:12 EST
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 16:36:33 EST
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 16:37:41 EST
(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 16:45:30 EST
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 17:19:16 EST
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 15:07:16 EDT
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
groups. 

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 16:12:01 EDT
I still think fixing Bug 81255 is a more generic solution which would allow the
same result
Comment 7 Matthew Miller 2003-04-09 16:32:56 EDT
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 17:16:58 EDT
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-06 22:15:21 EDT
Patch works unchanged on 1.68 from rawhide.
Comment 10 Matthew Miller 2004-01-22 17:46:46 EST
Created attachment 97199 [details]
updated for 1.69-3

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

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 15:15:26 EST
Continuing conversation with myself.... Patch applies cleanly to
1.69-4; haven't tested extensively. I'll do that when Fedora Core 2 is
released.

Still looking for suggestions for a better term than "UGROUPS".
Comment 12 Matthew Miller 2004-04-02 14:27:24 EST
Created attachment 99080 [details]
patch to userhelper man page

Adds documentation for UGROUPS and USER=<none> features to the man page for
userhelper.
Comment 13 Matthew Miller 2004-04-02 14:28:50 EST
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 13:19:11 EDT
patch applies cleanly to 1.70-2.
Comment 15 Matthew Miller 2004-04-15 16:35:42 EDT
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 10:46:38 EDT
Please consider for Fedora Core 3. Thanks.
Comment 17 Alan Cox 2004-07-10 10:49:50 EDT
Looks sensible but doesn't apply to CVS head btw
Comment 18 Matthew Miller 2004-07-10 12:40:28 EDT
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 12:49:32 EDT
PS: the changelog for usermode says:

  * Tue Jul 1 2004 Dan Walsh <dwalsh@redhat.com> 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 17:02:32 EDT
Putting on target tracking bug, since I think we should target at
least commenting on this patch.
Comment 21 Matthew Miller 2004-10-14 13:49:51 EDT
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 04:40:33 EDT
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
view?
Comment 23 Daniel Walsh 2004-10-15 13:38:13 EDT
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.

Dan
Comment 24 Daniel Walsh 2004-10-15 14:36:39 EDT
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.

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

Mathew, thanks for them!
Comment 26 Jindrich Novy 2004-10-20 04:52:22 EDT
*** Bug 81255 has been marked as a duplicate of this bug. ***
Comment 27 Matthew Miller 2004-10-20 09:17:58 EDT
Cool, thanks!
Comment 28 Christopher Brown 2007-06-19 10:26:01 EDT
Hello,

Re-opening this bug as discussed in:

https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01903.html

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 10:35:53 EDT
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.
Thanks.

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