Bug 442181

Summary: AVC denial when redirecting X server output to a file
Product: [Fedora] Fedora Reporter: Bill Crawford <billcrawford1970>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED WONTFIX QA Contact: Ben Levenson <benl>
Severity: low Docs Contact:
Priority: low    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-06 21:12:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Bill Crawford 2008-04-12 14:37:37 UTC
Description of problem:
Apr 12 13:01:43 pikachu kernel: type=1400 audit(1208001703.612:9): avc:  denied
 { write } for  pid=8648 comm="X" path="/home/bill/X.log" dev=dm-9 ino=10092547
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

Version-Release number of selected component (if applicable):

How reproducible:
Redirect X server output to a file when running as (unconfined, in theory) user
as follows: mv -f X.log X.log.old ; startx -- -accessx >&X.log

Steps to Reproduce:
1. Run X redirected to file as above
2. Wait for it to print something
3. See denial
Actual results:
AVC denial (am in permissive mode currently, as I've encountered a lot of these

Expected results:
Since I'm allowed to see the server's output I should be able to write it to a
file I own.

Additional info:

Comment 1 Daniel Walsh 2008-05-02 20:00:14 UTC
This is a know issue which we don't have a good solution to, until we update the
kernel with open perms.

You might be able to get this to work by executing 

mv -f X.log X.log.old ; startx -- -accessx | cat >&X.log

Or if you change the context of x.log to xserver_log_t

touch X.log
chcon -t xserver_log_t X.log

Comment 2 Bill Crawford 2008-05-03 14:16:08 UTC
Yeah, I realise it's a bit of ... can of worms. The latter solution (changing
the context) looks good. If only there were some way of having that done
automatically ....

I take this is but one example of the clash between the "do what you need to do
and drop privilages" paradigm and the SELinux one ;o)

Comment 3 Bill Crawford 2008-05-03 14:16:38 UTC
I might just set the context and then *copy* the file ...

Comment 4 Daniel Walsh 2008-05-06 21:12:04 UTC
There is a new feature coming where the kernel separates out the access of open
versus just read/write.  Currently we can not differentiate one process handing
an open file descriptor for read/write from a process actually opening a file
for read/write.

So once we have this feature we can add boolean support to allow domains to
read/write files in users homedir but never open them.  This would allow your
example where bash is actually opening the file as unconfined_t and then handing
the open filedescriptor to xserver_t.