Description of problem: While logged in as root I can't su to user accounts. Version-Release number of selected component (if applicable): kernel-2.6.3-1.91 coreutils-5.0-40 libselinux-1.4-10 How reproducible: Always Steps to Reproduce: 1. Log in as root 2. su - someuser Actual results: It will stay as root. If you look in /var/log/messages there'll be: Feb 20 14:58:55 someuser su[2982]: Could not open stdin terminal descriptors for /dev/tty1. Permission denied. Feb 20 14:58:55 someuser su[2982]: Could not open stdout terminal descriptors for /dev/tty1. Permission denied. Feb 20 14:58:55 someuser su[2982]: Could not open stderr terminal descriptors for /dev/tty1. Permission denied. Expected results: It should change user id to that of someuser. Additional info: getenforce says it's in permissive mode. After reboot with selinux=0 specified at kernel command line it works as expected.
What is the protection on the /dev/tty1? The pam_selinux module is changing the terminal security context and then closing and reopening the terminal. For some reason when it reopens the terminal it gets an error. Did you relabel the file system with SELinux? Currently the installer does not fully support labeling all files, so you end up in a sort of sudo SELinux envioronment, you can relabel the file system to get it in a full SELinux environment. Several things can be done to solve this problem. You can edit the /etc/pam.d/su file and add nottys to the pam_selinux.so line and this will stop trying to relabel the terminals, or you could remove this line and it will go back to the default behaviour and not attempt to transition you do a different context. Dan
What kind of "protection"? Do you mean SELinux label or policy? I have policy-1.6-1 installed and I did relabel the file system using setfiles utility and file_contexts from policy-sources. Adding nottys to pam_selinux.so works, thank you for this solution. Of course, this is a mere workaround and not fixed the bug itself. BTW, it seems that nobody testing FC2 logged in as root. There are dozens of denied operations in that setup. And some things simply don't work even in permissive mode. Rebuilding coreutils from source rpm comes to mind (I suppose a su is to blame here as well). I don't even try to report it, because opening so many similar bug reports doesn't make sense. And I have not enough knowledge of SELinux to fix it myself :-(