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

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 
GNU/Linux
[vnmr1@pt5 ~]$ rpm -qa | grep xterm
xterm-192-1
[vnmr1@pt5 ~]$ rpm -qa | grep linux
selinux-doc-1.14.1-1
selinux-policy-targeted-1.17.30-2.52.1
linuxdoc-tools-0.9.20-14
selinux-policy-targeted-sources-1.17.30-2.52.1
linuxwacom-0.6.4-6
libselinux-1.19.1-7
util-linux-2.12a-16.EL4.6
syslinux-2.11-1
libselinux-devel-1.19.1-7
linuxwacom-devel-0.6.4-6
[vnmr1@pt5 ~]$ ls -l /dev/console
crw-------  1 vnmr1 root 5, 1 Nov 29 15:03 /dev/console

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.

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.

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 . 

This is fixed in the u2 policy.

I do not understand what this means. What do I need to do to get a fix?

up2date should get you the latest policy files.

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.

Is there any news or progress on this bug?

Try selinux-policy-targeted-1.17.30-2.126

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

This is U3 policy.

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???

You should be able to update policycoreutils?


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

I can confirm that this bug is resolved with selinux-policy-targeted-1.17.30-2.126

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!

(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
policycoreutils-1.18.1-4.9.x86_64.rpm.

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...

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.

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...?

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.

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:

http://www.linuxfromscratch.org/hints/downloads/files/xconsole_setup.txt

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 
messages...

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...

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.

http://rhn.redhat.com/errata/RHBA-2006-0373.html