Bug 115117 - broken assumption: logged-in X session user owns VC
broken assumption: logged-in X session user owns VC
Product: Red Hat Linux
Classification: Retired
Component: usermode (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2004-02-06 14:41 EST by Robert M. Riches Jr.
Modified: 2007-04-18 13:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-09 18:20:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
write-up of steps sufficient to enable shutdown or reboot (2.06 KB, text/plain)
2004-02-09 18:09 EST, Robert M. Riches Jr.
no flags Details

  None (edit)
Description Robert M. Riches Jr. 2004-02-06 14:41:57 EST
Description of problem:
The usermode package appears to be based on a broken
assumption, that a user who is logged in and running
an X session owns one of the virtual text consoles
(one of the VCs).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. In runlevel 3, log in as non-root Gnome user.
2. With /bin/csh, run "startx </dev/null >& startx.log &".
3. Wait for X session to materialize.
4. (Do Alt-Ctrl-F1) Exit from the VC text console shell.
5. (Do Alt-Ctrl-F7) Use the Gnome menu logout function.
Actual results:
User is not given the option to reboot or shutdown.
Also, user is not given permission to sound and other
devices unless /etc/security/console.perms is modified.

Expected results:
User should be given the options to reboot and shutdown.
User of X session should be given access to sound and
other devices controlled by /etc/security/console.perms.

Additional info:
It is arguably better to use runlevel 3 than 5.  It is
arguably better to direct startx's stdout and stderr to
a log file and exit the text console shell after starting
X.  (In a professional environment, policies often require
using xlock when away from the workstation.  If the text
console shell is left active, an attacker can switch to
that console, hit control-Z or control-C and gain access
to the user's account.)  Besides, no useful function is
served by keeping the text console shell active, and the
console should arguably be freed up by exiting the shell.

Accordingly, usermode should also look for an active X
session to grant the privileges now granted only to one
who owns a text console.

Perhaps this should be directed to pam_console.so rather
than usermode.

By the way, my startx script (modifed as encouraged in
the comments in the file) gives each user a separate X
display, so multiple users can be simultaneously running
separate X sessions.  (That can cause a lot of paging,
but it works.)
Comment 1 Nalin Dahyabhai 2004-02-06 14:58:19 EST
An active X session on the local host is insufficient to determine if
a user is actually at the system console -- a user logged in via ssh
can open one using Xnest.
Comment 2 Robert M. Riches Jr. 2004-02-06 16:00:53 EST
That's a good point about Xnest.  So, there isn't any
reasonable way to tell whether a user is running a
purely local X session?

On a related note, the Customization Guide shows how to
disable console program access, but it has nothing about
how to enable access to shutdown, poweroff, halt, and
reboot in cases when that is needed.  Where should I
submit an RFE for the Customization Guide?

A Google search shows a (slightly overbroad) way to
enable access to shutdown is to replace the symlinks to
consolehelper with symlinks to /sbin, and change the
permission bits of the /sbin executables.  However,
what if Gnome still doesn't recognize the user has
execute permission.

Or, would a better way to enable such user access be
to edit /etc/pam.d/{reboot,halt,poweroff}.  Any

Comment 3 Nalin Dahyabhai 2004-02-06 16:12:46 EST
There's no way that I can think of (it's a local socket, so it looks
as "local" as anything else, the only difference is the display
number, and if you're in runlevel 3, then you can't be sure that ":0"
is local because a remote user may be using that display number).

If you want to disable access to applications which need to run with
elevated privileges (like shutdown, poweroff, halt, and most of the
configuration tools), you can simply uninstall the usermode package.

If you're looking at modifying how access is granted, you have an
additional problem to solve:  the gnome-session package's logout.c
contains special code to examine the contents of the pam_console lock
files to determine if the user should be presented with the
reboot/shutdown options -- if there's an alternate mechanism, it would
need to be modified to understand it was in place and display the
options for that case.

That solved, modifying /etc/pam.d/{reboot,halt,poweroff} is the method
I'd recommend for modifying the policy of who's allowed to run these
commands.  The pam_listfile module may be sufficient for your needs,
though it can't distinguish between local and remote logins, so I
can't say for certain.
Comment 4 Robert M. Riches Jr. 2004-02-06 16:24:37 EST
Thanks for the information.

Actually, my present need is to _enable_ access to the
reboot and shutdown functions from Gnome's logout menu
item.  It sounds like gnome-session's logout.c may be
where I need to go.  Either that or a custom menu item
or some other way.  Hmmm, how to exit a Gnome session
and then trigger shutdown from outside Gnome...

For cases where I need to disable access, the existing
documentation in the customization guide is very good.
Comment 5 Robert M. Riches Jr. 2004-02-09 18:09:15 EST
Created attachment 97543 [details]
write-up of steps sufficient to enable shutdown or reboot

Just in case it might be of some use to someone at some future time,
I'm attaching a short write-up of how I enabled access for a user
who does not own a VC (virtual text console) to use the Gnome popup
box to shut down (or reboot) the system.  Is there a process for
requesting/suggesting something like this be added to the customization
Comment 6 Nalin Dahyabhai 2004-02-09 18:20:53 EST
Requests for changes to docs are like any other change -- a bug with
severity = "enhancement", filed for the customization guide ("rhl-cg")
component.  Marking wontfix because there's no change being made to
usermode here.

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