Bug 487528
Summary: | sshd getting wrong type for root (/) directory, preventing chdir | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | mgm <mobleym> | ||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 10 | CC: | kernel-maint, sdsmall | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2009-12-18 08:03:38 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
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. 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 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 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. |
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.