Bug 450804 - SELinux is preventing the ntpd from ... (/home/u/.xsession-errors)
Summary: SELinux is preventing the ntpd from ... (/home/u/.xsession-errors)
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-applets
Version: 9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-11 04:40 UTC by xunilarodef
Modified: 2009-06-10 10:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-06-10 10:36:37 UTC
Type: ---

Attachments (Terms of Use)

Description xunilarodef 2008-06-11 04:40:34 UTC
Description of problem:
The setroubleshoot browser states "SELinux has denied ntpd access to 
potentially mislabeled file(s) (/home/u/.xsession-errors)".  But
the file label seems plausible to me, so I wonder if this is really a
policy error, or must we re-engineer how ntpd communicates with the

  More interestingly, if one changes SELinux to run in permissive mode,
(via System, Administration, SELinux management, in Status pane change 
"Current Enforcing Mode" from "Enforcing" to "Permissive"), the lines
that are written to ~/.xsession-errors are:

** (gnome-panel:3259): WARNING **: panel-applet-frame.c:1285: failed to load
applet OAFIID:TomboyApplet:

even though Tomboy is not currently (and never has been) in use, but
I gather it is now a standard part of the mono-infection of gnome-applets.
This behavior and content was quite repeatable with
gnome-applets-2.22.1-2.fc9.i386.  After the update to
gnome-applets-2.22.2-1.fc9.i386 the AVC denial is still just as repeatable,
but even when running in SELinux permissive mode, no new lines are 
written to ~/.xsession-errors. ??

Version-Release number of selected component (if applicable):
gnome-applets-2.22.1-2.fc9.i386 [first observed with]
gnome-applets-2.22.2-1.fc9.i386 [still happens with]
selinux-policy-3.3.1-55.fc9.noarch [first observed with]
selinux-policy-3.3.1-62.fc9.noarch [still happens with]

How reproducible:
  Once is enough for bugs of this sort, but I have seen it repeatedly.

Steps to Reproduce:
1.  Enable ntp on a system where it was most recently disabled via
    System, Administration, Date & Time, authenticate as root,
    Network Time Protocol tab, [select checkbox] Enable Network Time Protocol

Actual results:
Top panel popup appears stating "SELinux AVC denial, click to view".
The time displayed in the top panel clock is updated appropriately
by ntpd (if needed), without triggering any further denials. 

Expected results:
Safely record the information in ~/.xsession-errors
don't try to write unrelated gibberish in ~/.xsession-errors

Additional info:

Source Context: unconfined_u:system_r:ntpd_t:s0
Target Context: system_u:object_r:user_home_t:s0
Target Objects: /home/u/.xsession-errors [ file ]
Source: ntpd
Source Path: /usr/sbin/ntpd
Port: <Unknown>
Host: localhost.localdomain
Source RPM Packages: ntp-4.2.4p4-6.fc9
Target RPM Packages:
Policy RPM: selinux-policy-3.3.1-55.fc9
Selinux Enabled: True
Policy Type: targeted
MLS Enabled: True
Enforcing Mode: Enforcing

Nitpick:  I have yet to see an instance of this error message where
the presence of the word "the" in front of the program name does not
seem to be a stumbling block (as perceived in a American dialect of
English).  Should this extra word be removed? 
 SELinux is preventing the ntpd from ...
 . . . . . . . . . . . --- . . . . . ...

Comment 1 Daniel Walsh 2008-06-11 12:56:28 UTC
This avc is basically reporting that stdout/stderr were changed by the login
programs to redirect to ~/.xsession-errors.  Since we want to prevent system
daemons from writing to the homedir, this is not allowed.  The kernel closes the
file descriptors and redirects them to /dev/null.  So everything works fine,
except the AVC gets generated.

THis can safely be ignored.  We have an updated kernel coming that includes the
open access, so we will be able to differentiate between rear/write of open file
descriptors handed to a processes from the process actually opening a file.

Comment 2 Bug Zapper 2009-06-10 01:32:27 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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: 

Comment 3 Daniel Walsh 2009-06-10 10:36:37 UTC
This works in F10 and F11.

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