Bug 487528 - sshd getting wrong type for root (/) directory, preventing chdir
sshd getting wrong type for root (/) directory, preventing chdir
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-26 10:44 EST by mgm
Modified: 2009-12-18 03:03 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 03:03:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of sealert (3.50 KB, text/plain)
2009-02-26 10:44 EST, mgm
no flags Details

  None (edit)
Description mgm 2009-02-26 10:44:59 EST
Created attachment 333339 [details]
Output of sealert

Description of problem:   sshd reporting wrong type for root (/) directory, preventing chdir to user's home.  


Version-Release number of selected component (if applicable):
Components of ssh:
openssh-clients-5.1p1-3.fc10.i386
libssh2-0.18-7.fc9.i386
openssh-server-5.1p1-3.fc10.i386
openssh-askpass-5.1p1-3.fc10.i386
openssh-5.1p1-3.fc10.i386

SE Linux:
selinux-policy-3.5.13-45.fc10.noarch
selinux-policy-targeted-3.5.13-45.fc10.noarch
libselinux-devel-2.0.73-1.fc10.i386
libselinux-utils-2.0.73-1.fc10.i386
libselinux-python-2.0.73-1.fc10.i386




How reproducible:  Completely reproducible


Steps to Reproduce:

Attepmt to log in with:  'ssh user@zoe'

I get the message: 
  Could not chdir to home directory /local/home/user: Permission denied

I check /var/log/messages and see

Feb 26 10:16:30 zoe setroubleshoot: SELinux is preventing sshd (sshd_t) "search" to / (default_t). For complete SELinux messages. run sealert -l 3a090f7e-0bd0-43f4-9295-db6224f2e3c0

Run sealert as instructed.  Complete results attached.  Specifically, though, I see:

SELinux denied access requested by sshd. / may be a mislabeled. / default
SELinux type is root_t, but its current type is default_t. 

...and ...

Source Context                system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context                system_u:object_r:default_t:s0
Target Objects                / [ dir ]


HOWEVER, 'ls -Zd /' shows:

drwxr-xr-x  root root system_u:object_r:root_t:s0      /

So, either sshd is seeing the wrong context, or sealert is lying about it.  I don't know much about selinux, so I don't know which it is, and whether this is an sshd bug, an selinux policy bug, an sealert bug, or what...


Additional info:

Some peculiarities about my setup:  

I have a server and several client machines.  All are running Fedora 10.  This test is run on one of the clients.  Most of my user's home directories are on the server, and are NFS-mounted using autofs.  Logins are done via NIS (YP), and the autofs maps are also provided from the server to the clients by NIS.  All of this works perfectly on all machines, including the client used for this test.

On this particular client machine, however, I created a test user that is ONLY present on the client machine.  I have very specific reasons for doing it this way.  As such, the login info is in the local machine's /etc/passwd, etc...  Further, the user's home dir is in a local directory rather than the usual NFS mounted one.  Specifically, the local-only user's home is in "/local/home/user".  Permissions and contexts of these directories are correct as far as I can tell, and once logged in, the user can access his files just fine.  In fact, logging in as the user with 'su - user' for example works fine.  Only ssh has a problem.

What has me stumped about this is that the complaint that gets logged is about a file context problem on the system's root directory '/', not /local/home/user or any of those subdirs.  Further, the report produced by sealert says that the type on / is default_t, while ls -Z shows root_t.  That is why I'm reporting this as a bug.

Note also that I have not changed the contexts on /, and that I tried doing an autorelabel and that did not correct this issue.
Comment 1 Daniel Walsh 2009-03-02 21:45:33 EST
THe problem is on /local which is labeled default_t.  You should change it label

semanage fcontext -a -t home_root_t /local
restorecon /local

Which will fix the sshd problem.

sealert is trying to intepret the information given to it from the kernel.

node=zoe.xxxxxxxxxx.net type=AVC msg=audit(1235661390.69:228): avc:  denied  { search } for  pid=12641 comm="sshd" name="/" dev=sdb1 ino=2 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir

node=zoe.xxxxxxxxxx.net type=SYSCALL msg=audit(1235661390.69:228): arch=40000003 syscall=12 success=no exit=-13 a0=1358b00 a1=1351fe8 a2=ebbee4 a3=1351848 items=0 ppid=12640 pid=12641 auid=3000 uid=3000 gid=3000 euid=3000 suid=3000 fsuid=3000 egid=3000 sgid=3000 fsgid=3000 tty=pts1 ses=24 comm="sshd" exe="/usr/sbin/sshd" 
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

It is looking at the name field name="/" and reporting this as a problem.  So I would say this is a kernel bug, in that it is reporting the wrong object.

I will let the kernel guys look at this.
Comment 2 mgm 2009-03-03 12:39:56 EST
Thank you!

I confirmed that changing context of /local to home_root_t does indeed fix the sshd problem.

Incidentally, in light of the kernel reporting the wrong object ('/') were you able to determine that /local was actually the problem from something else in the sealert output (something I missed) or did you just know from experience?

Thanks,
--mgm
Comment 3 Bug Zapper 2009-11-18 06:14:17 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Bug Zapper 2009-12-18 03:03:38 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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