Stephen Smalley wrote:
That message just shows you that permission was granted to switch enforcing mode, so /usr/sbin/getenforce should now show that you are now in Permissive mode, i.e. SELinux will only log permissions that would be denied by policy but not actually enforce the denial. If it is still broken, then the SELinux kernel permission checks are unlikely to be the cause.
getenforce does indeed show Permissive after running setenforce 0, so at least that's working as expected. I can see how this seems like it would make it unlikely to be a SELinux problem at this point, but then how come I still see this when trying to su?
Warning! Could not relabel /dev/pts/3 with user_u:object_r:devpts_t, not relabeling.Operation not permitted
Interestingly, if I try to ssh in, instead of su, I get this:
[root@dumont ~]# ssh nagios@localhost nagios@localhost's password: Last login: Fri Sep 2 11:40:25 2005 from dumont -bash: /etc/profile: Permission denied
[root@dumont nagios]# ls -alZ drwx------ nagios nagios root:object_r:user_home_dir_t . drwxr-xr-x root root system_u:object_r:home_root_t .. -rw------- nagios nagios user_u:object_r:user_home_t .bash_history -rw-r--r-- nagios nagios root:object_r:user_home_t .bash_logout -rw-r--r-- nagios nagios root:object_r:user_home_t .bash_profile -rw-r--r-- nagios nagios root:object_r:user_home_t .bashrc -rw-r--r-- nagios nagios root:object_r:user_home_t .emacs -rw-r--r-- nagios nagios root:object_r:user_home_t .gtkrc -rw-r--r-- nagios nagios root:object_r:user_home_t .zshrc
.... so it still seems like SELinux is hurting me, even though it's set to be in permissive mode?
Not sure it will work on FC3, but try enabling syscall auditing: /sbin/auditctl -e 1 And then try again.
This didn't seem to have any impact I could see...