Description of problem: If you do "su -" to login as root, it does not switch to root's home directory. If you do "su -" from a user with a defined admin role, then it works normally. Here is the message I get when I "su -": su: warning: cannot change directory to /root: Permission denied When I get control back, I can do "cd /root" no problem.
Same here: [brandon@localhost brandon]$ su - Password: su: warning: cannot change directory to /root: Permission denied [root@localhost brandon]# cd /root/ [root@localhost root]# ls anaconda-ks.cfg install.log install.log.syslog
*** Bug 119768 has been marked as a duplicate of this bug. ***
*** Bug 119747 has been marked as a duplicate of this bug. ***
This is fixed in policy-1.9.2-12 (probably earlier). Could someone confirm it please?
Created attachment 99171 [details] log file of failed su command
The problem still occurs with policy-1.9.2-12. Log attached. The error only occurs on first 'su -l' command. While that terminal is active, then other 'su -l' commands do not cause the error.
So you are saying that this happens the first time after install? Dan
No, it happens everytime when a user issues the 'su -l' command and the user does not currently have an existing terminal executing the 'su -l' command. So when I first login as a normal user and issue the 'su -l' command, access is denied to the root directoy. Subsequent 'su -l' commands issued while the original is still active do not result in the access denied message (selinux is permissive). If all su commands are completed, then the next su command will cause the same error.
not to be too contrary but this is not happening any longer .. latest policy 1.9.2-13 and more or less latest other stuff from development (rawhide) that does not have a dependency problem.
Gene is right. The change to dir root is now successful. Logs before policy-1.9.2-12 had 'avc denied {search}' on root following a su command. After updating to policy-1.9.2-12 that message does not appear. The 'avc denied {write}' on dir root appears in all logs after a su command (even with policy-1.9.2-12) when the system tries to write to .xauthicRsQL file in root directory. I do not know if that is a problem.
Do you still see messages with policy-1.11.2-9? If so, try 'restorecon /root/.default_contexts'.
Grr, somehow I didn't see the messages that I got here before. Here they are, so we know what we're looking at. These are from 'setenforce 0', and 'su -' as user_r: audit(1082380940.349:0): avc: denied { search } for pid=10404 exe=/bin/su name=.xauth dev=hda6 ino=261622 scontext=user_u:user_r:user_su_t tcontext=system_u:object_r:user_home_t tclass=dir audit(1082380940.405:0): avc: denied { add_name } for pid=10404 exe=/bin/su name=.xauth0RPfrD scontext=user_u:user_r:user_su_t tcontext=root:object_r:staff_home_dir_t tclass=dir audit(1082380940.406:0): avc: denied { create } for pid=10404 exe=/bin/su name=.xauth0RPfrD scontext=user_u:user_r:user_su_t tcontext=user_u:object_r:staff_home_dir_t tclass=file audit(1082380940.406:0): avc: denied { setattr } for pid=10404 exe=/bin/su name=.xauth0RPfrD dev=hda2 ino=3817689 scontext=user_u:user_r:user_su_t tcontext=user_u:object_r:staff_home_dir_t tclass=file The thing that doesn't work in enforcing mode is (predictably) XAUTHORITY stuff. I.e. you can't 'su -' from a gnome-terminal, and run an xclock as root. audit2allow says: allow user_su_t staff_home_dir_t:dir { add_name }; allow user_su_t staff_home_dir_t:file { create setattr }; allow user_su_t user_home_t:dir { search };