Bug 174434
Summary: | xterm -C gives cannot open console : Operation not permited | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | dan iverson <dan.iverson> |
Component: | selinux-policy-targeted | Assignee: | Russell Coker <rcoker> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | bert.heise, jvdias |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | RHBA-2006-0373 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-08-10 21:19:35 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: | |||
Bug Depends On: | |||
Bug Blocks: | 181409 |
Description
dan iverson
2005-11-28 23:44:39 UTC
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 |