Bug 196343

Summary: consolehelper scalability (act more like sudo)
Product: Red Hat Enterprise Linux 4 Reporter: Jack Neely <jjneely>
Component: usermodeAssignee: Miloslav Trmač <mitr>
Status: CLOSED WONTFIX QA Contact: Kevin Baker <kbaker>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: ineilsen, redhat-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 16:02:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jack Neely 2006-06-22 17:28:55 UTC
Description of problem:

The consolehelper utility should act more like sudo.  Instead of knowing the
root password administrators should be able to use their passwords if they are
defined as administrators (ie listed in the sudoers file).  There is an existing
path to allow similar functionality for folks in a specific group (like wheel)
but this approach does not scale to large institutions.

Reference:
http://www.redhat.com/archives/fedora-desktop-list/2005-March/msg00001.html

Context:  I'm interested more so in scalability/management concerns as I
maintain RHEL for all of NC State University more so than the above thread's
focus on usability.

At NCSU we use a modified version of RHEL to deploy Linux throughout campus. 
Part of our modifications allow RHEL to use our kerberos/ldap/hesiod
infrastructure to handle usernames, passwords, and authentication.  So to add a
single user to the wheel group (for example) makes that person in the wheel
group on every single RHEL machine on campus. 

There are many IT groups with different skill sets responcible for sets of RHEL
machines on campus and ideally this works as a hierarchy.  We have
infrastructure to maintain a root password and list of administrators for each
of these groups.  The physics administrators are allowed to admin their machines
but do not have permission to do administrative tasks to the Computer Science
machines or the university level file servers or email servers.

Furthermore, while individual IT groups do have the root password for their
machines these passwords are not normally given out to all administrators.  For
example, a couple people in Engineering know the root password for their
machines but most of the IT staffers in Engineering do not.  Instead they use
ksu (yes, kerberized su) or sudo for administrative tasks.  This also creates an
audit trail.  

So at this level of scalability the consolehelper application is not very
helpful as most of the administrators that encounter it do not know the root
password but do have root level access to the machine.

I'd like to see a more sudo-ish consolehelper in RHEL 5.

Version-Release number of selected component (if applicable):
All versions.  Fedora Core and RHEL.

Comment 1 Jason Corley 2006-06-26 14:53:58 UTC
I am also encountering the same problem.

Comment 2 Edward Rudd 2006-10-17 18:49:02 UTC
this is a duplicate of bug 185517 which also includes a temporary workaround in
bug 185517, comment 2

Comment 3 Miloslav Trmač 2007-03-17 02:42:27 UTC
Thanks for your report.

usermode-1.74 in RHEL4 does include the UGROUPS feature described in bug 185517
(coming from bug 86188).  Is that, maybe with using a group for administrators
of each department, an acceptable solution?

Alternatively, could you use whatever mechanism you currently use for
distributing per-department sudoers files to distribute
/etc/security/console.apps/* files?

What requirements does "more like sudo" mean, specifically?  usermode can't very
well parse the /etc/sudoers file and maintain complete feature parity with sudo.

Comment 5 Jiri Pallich 2012-06-20 16:02:40 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.