Bug 174434 - xterm -C gives cannot open console : Operation not permited
xterm -C gives cannot open console : Operation not permited
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: selinux-policy-targeted (Show other bugs)
4.0
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:
Environment:
Last Closed: 2006-08-10 17:19:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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:
Always

Steps to Reproduce:
1.xterm -C
2.
3.
  

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


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

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

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

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