| Summary: | gdm-session-worker can't write .xsession-errors file because of incorrect fcontext when using non-local (network) login | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Josh Cogliati <jrincayc> |
| Component: | samba | Assignee: | Guenther Deschner <gdeschner> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | asn, bmourelo, dominick.grift, dwalsh, gdeschner, jbrier, jlayton, mgrepl, ssorce, tmraz |
| Target Milestone: | --- | Keywords: | Reopened, SELinux |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-08-07 19:51:05 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
This is mislabeled files. You need to run # restorecon -R -v /home/<username>/.xsession-errors When using winbind for authentication restorecon does not switch .xsession-errors to system_u:object_r:xdm_home_t I am guessing this is because the home directory is not /home/username, but instead /home/DOMAIN/username. Output from commands (Replaced my domain with NAME-NT and my username with username) # restorecon -R -v /home/NAME-NT/username/.xsession-errors # ls -Z /home/NAME-NT/username/.xsession-errors -rw-------. NAME-NT\username NAME-NT\domain users system_u:object_r:user_home_t:s0 /home/NAME-NT/username/.xsession-errors Josh can you add the following # semanage fcontext -a -e /home /home/NAME-NT # restorecon -R -v /home And then your labeling should be correct. Dan, Thanks, that did set the .xsession-errors file to the correct context. Do current versions of Fedora set the context correctly when /home/NAME-NT is first created? If they do, then I consider this bug closed, if not, then that should probably be fixed. Thanks. Is /home/NAME-NT A standard location or something you came up with? No, there is no standard location. The location is /home/NAME-NT where NAME-NT is the winbind domain. So if the winbind domain was ACME, the name would be /home/ACME. system-config-authentication would know the domain when it is run. I am not sure where else might have all the information needed to run semanage fcontext. Is there a tool to configure this? Does authconfig do this? I take it you are sharing a bunch of homedirs via SAMBA, over a active directory domain? I have not tried it, but I think authconfig --enablewinbindauth would probably do about the same thing as I have set up. Basically I am using active directory for authentication. Simo, do you know anything about this? Does authconfig do anything about configuring homedirs based on Windows Domains? No, authconfig does not configure this. I suppose this is a default in the winbind client code? (In reply to comment #3) > Josh can you add the following > > > # semanage fcontext -a -e /home /home/NAME-NT > # restorecon -R -v /home > > And then your labeling should be correct. Thanks to Josh figuring this out in comment #2 and for Dan's command I am able to login on Fedora 16. I am at Red Hat and I use ldap/kerberos for user info/authentication and as such my home directory is /home/rdu/jbrier so I ran into the same problem as here even though I am not using winbind. I think the title of this bug could be changed to something like gdm-session-worker can't write .xsession-errors when using non-standard /home path or something? I agree the name is inaccurate, since the problem is actually that the file context is not set properly when using any non-local authentication method, not just winbind. We are having another discussion just like this one about winbind moving to use oddjob to create user homedirs and then allow oddjob to setup proper SELinux labeling. This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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 |
Description of problem: selinux is preventing gdm-session-worker from writing a .xsession-errors file. Version-Release number of selected component (if applicable): selinux-policy-3.9.16-38.fc15 How reproducible: every time I manage to do something that causes gdm to try and write an error file. I don't really like giving xdm_t blanket write permission for the home directory however. Additional info: SELinux is preventing /usr/libexec/gdm-session-worker from 'write' accesses on the file /home/<NT domain username>/.xsession-errors. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that gdm-session-worker should be allowed write access on the .xsession-errors file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep gdm-session-wor /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:user_home_t:s0 Target Objects /home/<username>/.xsession-errors [ file ] Source gdm-session-wor Source Path /usr/libexec/gdm-session-worker Port <Unknown> Host (removed) Source RPM Packages gdm-3.0.4-1.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-38.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.40.4-5.fc15.x86_64 #1 SMP Tue Aug 30 14:38:32 UTC 2011 x86_64 x86_64 Alert Count 39 First Seen Fri 04 Feb 2011 08:14:41 AM MST Last Seen Wed 26 Oct 2011 04:15:44 PM MDT Local ID df072b62-4f7f-4a21-a833-dfb332f7b2e8 Raw Audit Messages type=AVC msg=audit(1319667344.79:76): avc: denied { write } for pid=1757 comm="gdm-session-wor" name=".xsession-errors" dev=dm-3 ino=1966102 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1319667344.79:76): arch=x86_64 syscall=ftruncate success=no exit=EACCES a0=e a1=0 a2=7fffb3146ed0 a3=1 items=0 ppid=1740 pid=1757 auid=16777216 uid=16777216 gid=16777216 euid=16777216 suid=16777216 fsuid=16777216 egid=16777216 sgid=16777216 fsgid=16777216 tty=(none) ses=1 comm=gdm-session-wor exe=/usr/libexec/gdm-session-worker subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Hash: gdm-session-wor,xdm_t,user_home_t,file,write audit2allow #============= xdm_t ============== #!!!! This avc is allowed in the current policy allow xdm_t user_home_t:file write; audit2allow -R #============= xdm_t ============== #!!!! This avc is allowed in the current policy allow xdm_t user_home_t:file write;