Bug 174434 - xterm -C gives cannot open console : Operation not permited
xterm -C gives cannot open console : Operation not permited
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: selinux-policy-targeted (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Russell Coker
Depends On:
Blocks: 181409
  Show dependency treegraph
Reported: 2005-11-28 18:44 EST by dan iverson
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2006-0373
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-10 17:19:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description dan iverson 2005-11-28 18:44:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
xterm -C gives an error message "cannot open console : Operation not permited".
It opens a terminal window but system log messages are not displayed.  This worked in RedHat Enterprise WS 3. If I take the xterm binary file from RHEL 3
and run it in the RHEL 4 environment, it also fails with the same error. Permissions on /dev/console are the same as they are in RHEL 3.

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

How reproducible:

Steps to Reproduce:
1.xterm -C

Actual Results:  xterm window opened. Error message "cannot open console : Operation not permitted". No system log messages are disdlayed

Additional info:
Comment 1 Jason Vas Dias 2005-11-28 20:26:21 EST
Please supply some further information to this bug report:

- Were you trying to run 'xterm -C' as a non-root user ?

'xterm -C' will NOT work as a non-root user, and will a non-console terminal
and emit the message:
 xterm: cannot open console: Operation not permitted
if 'xterm -C' is run as a non-root user . If RHEL-3 permitted non-root
users to view console messages, this was a bug.

If you are getting this problem when running 'xterm -C' as root:

I cannot reproduce this problem with xterm-192-1.EL4.0 and 
selinux-policy-targeted-1.17.30-2.110 (RHEL-4 Update 2+) .

- What versions of these packages are you running ?

- Does the problem go away if you run SELinux in Permissive mode ? - ie. do:
 # setenforce 0 ;  xterm -C
Comment 2 dan iverson 2005-11-29 18:04:28 EST
I am trying to run this as a non-root user. The xterm man page does NOT say 
that this option only works for root.  It says that it requires read/write 
access to /dev/console, which the non-root user has. If I try to run it as 
root, it still does not work. It still did not work after running setenforce 0.

 Some system information:
[vnmr1@pt5 ~]$ uname -a
Linux pt5 2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:30:39 EST 2005 i686 i686 i386 
[vnmr1@pt5 ~]$ rpm -qa | grep xterm
[vnmr1@pt5 ~]$ rpm -qa | grep linux
[vnmr1@pt5 ~]$ ls -l /dev/console
crw-------  1 vnmr1 root 5, 1 Nov 29 15:03 /dev/console

Comment 3 dan iverson 2005-11-29 19:03:53 EST
When I ran xterm as root, it did not complain about "cannot open console : 
Operation not permitted". However, it also did not display messages written 
to /dev/console.
Comment 4 Jason Vas Dias 2005-11-29 21:47:54 EST
Yes - you're not allowed to get console messages if you are not root - as 
enforced by the default permissions of the /dev/console device :
crw-------  1 vnmr1 root 5, 1 Nov 29 15:03 /dev/console
And programs such as xterm must have the CAP_SYS_ADMIN capability in order
to use the TIOCCONS ioctl that directs console output to a terminal device.

If you run 'xterm -C' as root, and (also as root) you do:
 # echo 'hello' >>/dev/console 
then 'hello' is displayed by the xterm.

Also, if you do not run syslogd, all log messages will appear on that xterm -C.

So this bug is NOT a problem with xterm or the kernel console redirection code.

I have found the problem - it is an SELinux issue .

Presumably you want to direct some log facility to the console , eg. with
an /etc/syslog.conf line like:
local6.crit /dev/console

If you restart syslogd from the initscript, ie. during boot or with 
'service syslog start', then syslogd will be unable to open /dev/console,
because the SELinux context syslogd_t does not have permission to open the
console_device_t /dev/console object in append mode.

So if you restart syslogd in Permissive mode:
 # setenforce 0; service syslogd restart
then syslogd is able to open /dev/console and log messages that are directed
to the console in /etc/syslog.conf do appear on the console and in xterm -C .

I'm moving this bug to the SELinux package.
Comment 5 Jason Vas Dias 2005-11-29 22:49:20 EST
syslogd is not permitted to open /dev/console by the SELinux policy.

In order for syslogd to be able to open /dev/console in write / append mode,
it needs :

  allow syslogd_t console_device_t:chr_file { ioctl read getattr write append };

It needs some other privilege to be able to actually write to the console with
writev() .

Unfortunately, no AVC messages were generated for failed open/write attempts by
syslogd to /dev/console . 
Comment 6 Daniel Walsh 2005-11-30 15:15:36 EST
This is fixed in the u2 policy.
Comment 7 dan iverson 2005-11-30 15:25:03 EST
I do not understand what this means. What do I need to do to get a fix?
Comment 8 Daniel Walsh 2005-11-30 17:17:05 EST
up2date should get you the latest policy files.
Comment 10 Jason Vas Dias 2005-11-30 18:05:04 EST
This is still not quite fixed with the U2 selinux-policy-targeted - we are
working on a fix and should hopefully have this fixed in a forthcoming RHEL
update release soon.
Comment 11 dan iverson 2006-01-31 16:34:10 EST
Is there any news or progress on this bug?
Comment 12 Daniel Walsh 2006-02-01 12:06:57 EST
Try selinux-policy-targeted-1.17.30-2.126

on ftp://people.redhat.com/dwalsh/SELinux/RHEL4/u3/noarch

This is U3 policy.
Comment 13 dan iverson 2006-02-03 18:22:30 EST
I tried to install the selinux-policy-targeted rpm, but it required
policycoreutils >= 1.18.1-4.9.  I could not install that (from your n3/i386 ftp
directory because it had file conflicts with policycoreutils-1.18.1-4. I could
not remove the older version because other rpms required it. I tried
using the file from rpmfind website policycoreutils-1.23.10-2.i386.rpm,
but it had additional rpm dependencies.  It is not clear were this dependency
tree will end.  What to do???
Comment 14 Daniel Walsh 2006-02-06 10:47:22 EST
You should be able to update policycoreutils?

Grab both the U3 policy and policycoreutils and execute
rpm -Uhv policycoreutils* selinux-policy*

Comment 15 Jason Vas Dias 2006-02-06 11:35:20 EST
I can confirm that this bug is resolved with selinux-policy-targeted-1.17.30-2.126
Comment 16 Russell Coker 2006-04-12 23:07:35 EDT
This bug needs one final fix.  Currently the RHEL4 policy grants write access 
to the console but not append access.  This causes a reload of syslogd to 
write an error message "syslogd: /dev/console: Permission denied" if there is 
a syslogd.conf line directly referring to /dev/console (such as the kernel 
line which is commented out in the config).

On the first attempt to open /dev/console syslogd will attempt append access 
and fail.  It will re-try with write access and log the error message - it's 
confusing to see a message on /dev/console saying that /dev/console could not 
be accessed!
Comment 21 Bert Heise 2006-04-20 16:55:58 EDT
(Working for the same company as Dan Iverson) I can confirm that this bug still
persists, even after installing selinux-policy-targeted-1.17.30-2.126,
selinux-policy-targeted-sources-1.17.30-2.126 and

I tried everything you suggested - "setenfore 0" (also set SELINUX=disabled in
/etc/sysconfig/selinux), restarted syslogd - still I get Console messages *only*
when starting "xterm -C" as root. Starting it as anyone else leads to no display
of messages sent to /dev/console (e.g. via "echo test > /dev/console). If
/dev/console belongs to anyone else than root, I also still get the "cannot open
console: Operation not permitted" error message. Please help, we have a real
problem because of this...
Comment 22 Jason Vas Dias 2006-04-20 17:22:41 EDT
In reply to the last Comment #21:

You cannot redirect the console as a non-root user - this is enforced by the
kernel - a user must have the CAP_SYS_ADMIN capability in order to successfully
issue the TIOCCONS ioctl that directs console output to a terminal device .

There were other problems with SELinux that prevented a root user being able
to redirect the console, but these are now fixed with the SELinux package
updates for this bug .

If you need to re-direct the console, do so as root, or in a child process of
a root process that has retained the CAP_SYS_ADMIN capability (could be 
done with a process that uses the prctl(PR_SET_KEEPCAPS call as root before
doing setuid()) - there is no other way around this in a userspace process.
Comment 23 Bert Heise 2006-04-20 20:07:08 EDT
The way we are working is that a user-started program running in the 
background (doing some automated stuff) issues status messages to the console.
Since RHEL4 we can no longer get these messages in a secure way - having a 
root console open all the time is not an option! 

Under Solaris it was never a problem and worked nicely under RHEL3 and RHEL3 
update2 but stopped working under RHEL4 - I don't understand why. Could one 
tweak the kernel otherwise to get it back and if so, how...?
Comment 24 Russell Coker 2006-04-21 01:35:11 EDT
Bert, firstly I tried to get a RHEL3 machine to act in the way you describe, 
but it would not do so.  When I ran "xterm -C" it did not display any errors, 
but it also didn't display data which was sent to /dev/console.

As Jason mentioned the TIOCCONS ioctl is used to read such data, due to the 
security implications of this it requires the CAP_SYS_ADMIN capability.

To satisfy your requirement for displaying /dev/console data without having a 
root console open, it would not be difficult to write a setuid root program 
that reads the data in question and displays it on standard output.  That 
program could then be run in a graphical environment if desired.
Comment 25 Bert Heise 2006-04-21 11:26:53 EDT
Hm, strange that it doesn't work for you under RHEL3: If under RHEL 3 (2.4.21-
4.EL to be exact) I run "xterm -C" as an ordinary user, /dev/console belongs 
to that user and he is allowed to write to it, it works just fine. 

I also tried to use xconsole: xconsole (that should display /dev/console) does 
not display anything and if I try "xconsole -file /dev/console" X11 goes 
totally crazy - all keyboard input is scrambled and I have to log out from X 
to recover... Trying the fix described here:


didn't lead me anywhere either - didn't work. I could compile the program and 
set the user/group/permissions right but still no display of console 
Comment 27 Bert Heise 2006-05-27 05:33:02 EDT
I finally found a livable workaround: 

- As root user, make yourself a short shell macro that could look like this 
(you may call it "console"):
  chown root /dev/console
  chmod a+rwx /dev/console
  touch /vnmr/tmp/console_dummy
  chmod a+rwx /tmp/console_dummy
  xterm -C -sb -sl 4096 -T "console" -e tail -f /vnmr/tmp/console_dummy &

(the "tail -f" part ist just to prevent the shell from getting a prompt)

- Copy it to /usr/local/bin and make it executable for everybody (only root 
should have write access, though): "chmod 755 console".

- As it has to be run with root permissions, edit the file /etc/sudoers and 
add a new line for each user who should be able to use this:

  user  hostname = NOPASSWD: /user/local/bin/console

- The user "user" can now issue the command via "sudo /vnmr/bin/console".

Surely not elegant, but does its job...
Comment 30 Red Hat Bugzilla 2006-08-10 17:19:36 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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