Usermode is the handy little program that makes all of the GUI administration utilities (and some command line tools too -- it's not picky) able to prompt for the root password when run as a normal user.
It also has a feature where users can, instead of authorizing as the root user, authorize as themselves with their own password.
This is good for things like changing GECOS information, or anything else where you want the user to demonstrate that they really are who they say they are rather than just someone who walked up to the console.
However, it's on an all-or-nothing basis -- either everyone must give the root password for a given program, or everyone can run it with their own password.
My patch implements what I call a "sudo-like" behavior (although it is much simpler than sudo). Each program, through its console.apps config file, can have a list of groups whose members are able to authorize as themselves. Anyone not a member of the approved groups either must give the root password (or the password of a given user, or is denied access completely via a new <none> value).
This could allow members of an admin group (traditionally, 'wheel') to have easy access to all of the administrative tools -- very reasonable for ease of use on a personal desktop system. Or, you could be more fine-grained, and give members of a certain group access to 'gtoaster' on a shared CD-burning system.
This all may sound complicated, but it's not. Usermode already implements 99% of what was needed -- the core patch is about a dozen lines! (There's also is_group_member and is_grouplist_member helper functions, but those are very simple too.)
And, it's a very non-evasive change, because if the config files aren't changed, it defaults to acting exactly like it does now.
See the patch, and the request, at:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188
Any comments/suggestions are very welcome.
And Nalin or whoever else, please consider adding this.
Thanks!
Matthew Miller (mattdm@mattdm.org) said:
This all may sound complicated, but it's not. Usermode already implements 99% of what was needed -- the core patch is about a dozen lines! (There's also is_group_member and is_grouplist_member helper functions, but those are very simple too.)
And, it's a very non-evasive change, because if the config files aren't changed, it defaults to acting exactly like it does now.
See the patch, and the request, at:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188
Any comments/suggestions are very welcome.
SELinux roles! :)
Bill
On Thu, Apr 15, 2004 at 05:28:46PM -0400, Bill Nottingham wrote:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188 Any comments/suggestions are very welcome.
SELinux roles! :)
I admit, I have not fully grokked how usermode works with SELinux. If you (or anyone, I'm not picky) could give me a five-second summary, that'd be great. :) I posted something to the Fedora SELinux list last month, and got an underwhelming amount of replies. (Um, none, really, except from someone who'd been working on an alternate way of doing exactly what my patch does.)
Anyway, my patch doesn't necessarily touch any of that -- it's dealing more with the simple issue of who needs to authenticate as whom, and doesn't much care how that actual authentication happens or what it results in.
On Thu, Apr 15, 2004 at 04:57:29PM -0400, Matthew Miller wrote:
My patch implements what I call a "sudo-like" behavior (although it is much simpler than sudo). Each program, through its console.apps config file, can have a list of groups whose members are able to authorize as themselves. Anyone not a member of the approved groups either must give the root password (or the password of a given user, or is denied access completely via a new <none> value).
Shoudn't this be already possible using PAM (e.g. pam_listfile)? Mirek
On Fri, Apr 16, 2004 at 02:58:27PM +0200, Miloslav Trmac wrote:
My patch implements what I call a "sudo-like" behavior (although it is much simpler than sudo). Each program, through its console.apps config file, can have a list of groups whose members are able to authorize as themselves. Anyone not a member of the approved groups either must give the root password (or the password of a given user, or is denied access completely via a new <none> value).
Shoudn't this be already possible using PAM (e.g. pam_listfile)?
I don't think so. How would you do it? The selection of user account to authorize against (root, or <user>, or even some other account) happens at a earlier/higher level.
On Fri, Apr 16, 2004 at 09:48:26AM -0400, Matthew Miller wrote:
On Fri, Apr 16, 2004 at 02:58:27PM +0200, Miloslav Trmac wrote:
My patch implements what I call a "sudo-like" behavior (although it is much simpler than sudo). Each program, through its console.apps config file, can have a list of groups whose members are able to authorize as themselves. Anyone not a member of the approved groups either must give the root password (or the password of a given user, or is denied access completely via a new <none> value).
Shoudn't this be already possible using PAM (e.g. pam_listfile)?
I don't think so. How would you do it? The selection of user account to authorize against (root, or <user>, or even some other account) happens at a earlier/higher level.
Ah, sorry. I have misread what you want to do. Mirek
On Fri, Apr 16, 2004 at 03:56:42PM +0200, Miloslav Trmac wrote:
Ah, sorry. I have misread what you want to do.
:) no problem.
On Fri, Apr 16, 2004 at 02:58:27PM +0200, Miloslav Trmac wrote:
On Thu, Apr 15, 2004 at 04:57:29PM -0400, Matthew Miller wrote:
My patch implements what I call a "sudo-like" behavior (although it is much simpler than sudo). Each program, through its console.apps config file, can have a list of groups whose members are able to authorize as themselves. Anyone not a member of the approved groups either must give the root password (or the password of a given user, or is denied access completely via a new <none> value).
Shoudn't this be already possible using PAM (e.g. pam_listfile)?
A module can change the value of PAM_USER and in that way change the user whose password is requested and verified by modules which are called later, yes. You'd then depend on the application to act appropriately in the case where this happens: it could continue using the PAM_USER setting as the user's name, it could ignore the change and continue on (IIRC what most applications do), or it could flag this as an error (what usermode currently does).
The pam_listfile module checks that the PAM_USER is in the list, or is a member of some group in that list, but it never modifies the PAM_USER item, so you can't accomplish what Matthew's describing by using the pam_listfile module.
Nalin