Bug 119455

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 };