service not starting via systemd but no AVCs are generated

[Dominick Grift]

On Tue, 2013-07-09 at 12:37 -0400, Eric Paris wrote:
> On Tue, 2013-07-09 at 18:06 +0200, Dominick Grift wrote:
> > On Tue, 2013-07-09 at 11:21 -0400, Daniel J Walsh wrote:
> > > On 07/09/2013 10:27 AM, Dominick Grift wrote:
> > > > On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
> > > >> On 07/09/13 21:06, Ed Greshko wrote:
> > > >> 
> > > >> 
> > > >> Sorry to be responding to myself....but....
> > > >> 
> > > >> It seems this AVC is the relevant one since /run is on tmpfs.
> > > >>> 
> > > >>> type=AVC msg=audit(1373375040.246:775): avc:  denied  { write } for
> > > >>> pid=3820 comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> > > >>> scontext=system_u:system_r:fail2ban_client_t:s0
> > > >>> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
> > > >> 
> > > >> Not being fluent in selinux....  Would this be a bug in the fail2ban
> > > >> policy module....  Or, something else?
> > > >> 
> > > > 
> > > > yes a bug in the fail2ban policy module
> > > > 
> > > > either the fail2ban client checks to see if /run/fail2ban is writable or it
> > > > actually wants to create something in there ( but there is currently no
> > > > trace of the latter)
> > 
> > I noticed that fedora uses the audit_access av perm wrong ( at least to
> > the best of my knowledge)
> > 
> > What fedora does:
> > 
> > dontaudit somedomain_t somefile_t:file audit_access;
> > 
> > How i believe it should be used:
> > 
> > dontaudit somedomain_t somefile_t:file write;
> > allow somedomain_t somefile_t:file audit_access;
> > 
> > Although, and i have not checked this, it sometimes seems that it does
> > not work either way. I still need to verify that. ( i might actually do
> > that now)
> 
> It is using it correctly.  audit_access is weird and special..
> 
> allow for the perm audit_access means nothing at all...
> 
> dontaudit somedomain_t somefile_t:file audit_access;
> 
> means we don't audit failures in the access(2) syscall, but we do audit
> failures on open/read/write...
> 
> We added this because nautilus does access(2) checks on every file in
> the world to decide how to display it on the screen.  We didn't want to
> hide users actually trying to open the file for read/write, but did want
> to hide all of the 'denials' from access(2)
> 
> Disabling dontaudit should make things show up even for access(2)....
> 

ok that explains it thanks
strange though because i seem to remember that the commit message for
this feature suggested otherwise. nonetheless now its clear to me