Bug 484587 - gdm-session-worker (xdm_t) needs to access .xsession-errors (user_home_t)
gdm-session-worker (xdm_t) needs to access .xsession-errors (user_home_t)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-08 13:47 EST by Göran Uddeborg
Modified: 2009-02-09 10:40 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-09 10:40:52 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)

  None (edit)
Description Göran Uddeborg 2009-02-08 13:47:04 EST
Description of problem:
Recently I noticed that my .xsession-errors no longer contains error messages from the session.  After a bit of debugging I figured out it is a newly upgraded selinux-policy that prevents gdm-session-worker from doing it's job.

Version-Release number of selected component (if applicable):
selinux-policy-3.5.13-40.fc10.noarch
selinux-policy-targeted-3.5.13-40.fc10.noarch

How reproducible:
Every time

Steps to Reproduce:
1.Log in via gdm and look for messages from applications in .xsession-errors

Additional info:
The AVC denials are apparently dontaudit:ed.  The only initial trace was a message

   gdm-session-worker[32429]: WARNING: unable to log session

But with "semodule -BD" I do get some messages, and running in permissive mode the functionality starts to work again.

The relevant code can be found in _open_session_log () in gdm-session-worker.c (see e.g. http://svn.gnome.org/svn/gdm/tags/GDM_2_24_0/daemon/gdm-session-worker.c).  The AVC messages I get are

time->Sun Feb  8 18:58:31 2009
type=SYSCALL msg=audit(1234115911.913:3691): arch=c000003e syscall=21 success=no
exit=-13 a0=eca280 a1=6 a2=e6eb40 a3=7fffc1b69250 items=0 ppid=32348 pid=32429 
auid=503 uid=503 gid=503 euid=503 suid=503 fsuid=503 egid=503 sgid=503 fsgid=503 tty=(none) ses=23 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" 
subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1234115911.913:3691): avc:  denied  { write } for  pid=32429 
comm="gdm-session-wor" name=".xsession-errors" dev=dm-0 ino=3852853 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
----
time->Sun Feb  8 18:58:31 2009
type=SYSCALL msg=audit(1234115911.914:3692): arch=c000003e syscall=77 success=no
exit=-13 a0=9 a1=0 a2=0 a3=7fffc1b69250 items=0 ppid=32348 pid=32429 auid=503 uid=503 gid=503 euid=503 suid=503 fsuid=503 egid=503 sgid=503 fsgid=503 tty=(none) ses=23 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1234115911.914:3692): avc:  denied  { write } for  pid=32429 comm="gdm-session-wor" name=".xsession-errors" dev=dm-0 ino=3852853 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file

and in the other case

time->Sun Feb  8 19:08:53 2009
type=SYSCALL msg=audit(1234116533.600:4203): arch=c000003e syscall=82 success=yes exit=0 a0=1f923a0 a1=1f92580 a2=5c86a60 a3=7ffff988af70 items=0 ppid=1526 pid=1564 auid=503 uid=503 gid=503 euid=503 suid=503 fsuid=503 egid=503 sgid=503 fsgid=503 tty=(none) ses=24 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1234116533.600:4203): avc:  denied  { rename } for  pid=1564 comm="gdm-session-wor" name=".xsession-errors" dev=dm-0 ino=3852853 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
Comment 1 Göran Uddeborg 2009-02-09 04:22:08 EST
Or am I fooling myself?  When logging in today on the very same machine, the xsession-errors file DID get rotated and updated.  Even though selinux is back in enforcing mode.

I'll make a few more tests.  Don't spend any time on this for a little while.
Comment 2 Daniel Walsh 2009-02-09 08:41:49 EST
xdm is only allowed to write to files labeled xdm_home_t, the problem here was that you had a file labeled user_home_t.  If you had run restorecon on the file it would have fixed it, or if you had removed the file, xdm would have created it on the next login, with the correct label.

I am not sure how it got labeled incorrectly in the first place.
Comment 3 Göran Uddeborg 2009-02-09 10:40:52 EST
> xdm is only allowed to write to files labeled xdm_home_t, the problem here was
> that you had a file labeled user_home_t.

And when I ran in permissive mode the file got replaced and got its correct type.  Yes, that makes sense.  I thought I did try a restorecon while looking for the problem, but maybe I did it on the wrong file or something.

All user's .xsession-errors (except mine) are still labeled user_home_t, so I'll do a bit more restoring of context.

Anyway, thanks for the explanation and sorry for the noise.

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