Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 119455 - "su -" does not change to root's home if done from regular user
"su -" does not change to root's home if done from regular user
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
: 119747 119768 (view as bug list)
Depends On:
Blocks: 122683
  Show dependency treegraph
Reported: 2004-03-30 12:52 EST by Gene Czarcinski
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-22 11:31:37 EDT
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-06 21:02 EDT, Paul Fulghum
no flags Details

  None (edit)
Description Gene Czarcinski 2004-03-30 12:52:23 EST
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 09:35:47 EST
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 03:44:43 EST
*** Bug 119768 has been marked as a duplicate of this bug. ***
Comment 3 Tim Waugh 2004-04-02 03:46:44 EST
*** Bug 119747 has been marked as a duplicate of this bug. ***
Comment 4 Tim Waugh 2004-04-05 18:57:20 EDT
This is fixed in policy-1.9.2-12 (probably earlier).

Could someone confirm it please?
Comment 5 Paul Fulghum 2004-04-06 21:02:19 EDT
Created attachment 99171 [details]
log file of failed su command
Comment 6 Paul Fulghum 2004-04-06 21:03:34 EDT
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-06 21:52:02 EDT
So you are saying that this happens the first time after install?

Comment 8 Paul Fulghum 2004-04-06 22:43:38 EDT
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 02:05:02 EDT
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 18:20:47 EDT
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 09:07:11 EDT
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 09:27:56 EDT
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.