Bug 119455 - "su -" does not change to root's home if done from regular user
Summary: "su -" does not change to root's home if done from regular user
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
: 119747 119768 (view as bug list)
Depends On:
Blocks: 122683
TreeView+ depends on / blocked
Reported: 2004-03-30 17:52 UTC by Gene Czarcinski
Modified: 2007-11-30 22:10 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-22 15:31:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
log file of failed su command (309 bytes, text/plain)
2004-04-07 01:02 UTC, Paul Fulghum
no flags Details

Description Gene Czarcinski 2004-03-30 17:52:23 UTC
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.

Comment 1 Brandon Petersen 2004-04-01 14:35:47 UTC
Same here:

[brandon@localhost brandon]$ su -
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

Comment 2 Tim Waugh 2004-04-02 08:44:43 UTC
*** Bug 119768 has been marked as a duplicate of this bug. ***

Comment 3 Tim Waugh 2004-04-02 08:46:44 UTC
*** Bug 119747 has been marked as a duplicate of this bug. ***

Comment 4 Tim Waugh 2004-04-05 22:57:20 UTC
This is fixed in policy-1.9.2-12 (probably earlier).

Could someone confirm it please?

Comment 5 Paul Fulghum 2004-04-07 01:02:19 UTC
Created attachment 99171 [details]
log file of failed su command

Comment 6 Paul Fulghum 2004-04-07 01:03:34 UTC
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.

Comment 7 Daniel Walsh 2004-04-07 01:52:02 UTC
So you are saying that this happens the first time after install?


Comment 8 Paul Fulghum 2004-04-07 02:43:38 UTC
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

Comment 9 Gene Czarcinski 2004-04-07 06:05:02 UTC
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.

Comment 10 Paul Fulghum 2004-04-07 22:20:47 UTC
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.

Comment 11 Tim Waugh 2004-04-19 13:07:11 UTC
Do you still see messages with policy-1.11.2-9?  If so, try
'restorecon /root/.default_contexts'.

Comment 12 Tim Waugh 2004-04-19 13:27:56 UTC
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
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
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 };

Note You need to log in before you can comment on or make changes to this bug.