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...
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
