From: dac.override@gmail.com (Dominick Grift)
Date: Thu, 28 Aug 2014 11:39:30 +0200
Subject: [refpolicy] [PATCH 4/7] Add attribute file_type to pseudo
 filesystem types
In-Reply-To: <1409209598.3998.3.camel@joe.localdomain>
References: <1408793751-11289-1-git-send-email-nicolas.iooss@m4x.org>
	<1408793751-11289-5-git-send-email-nicolas.iooss@m4x.org>
	<53FC7B94.3000001@tresys.com> <20140826145258.GA1464@e145.network2>
	<53FE52DB.8000605@m4x.org> <1409209598.3998.3.camel@joe.localdomain>
Message-ID: <1409218770.3998.8.camel@joe.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Thu, 2014-08-28 at 09:06 +0200, Dominick Grift wrote:
> On Wed, 2014-08-27 at 23:51 +0200, Nicolas Iooss wrote:
> 
> > > avc:  denied  { write } for  pid=674 comm="mount" name="/" dev="debugfs" ino=1 scontext=system_u:system_r:mount_t tcontext=system_u:object_r:debugfs_t tclass=dir permissive=0
> > >
> > > The mount command checks mountpoint file directories for write access
> > 
> > OK.  Just out of curiosity, is this write access expected or a kind of
> > bug that is silently denied by the refpolicy, which contains
> > files_dontaudit_write_all_mountpoints(mount_t) in system/mount.te?
> > 
> 
> In my view it should probably be:
> 
> dontaudit $1 mountpoint:dir audit_access
> 
> I have an interface called: files_audit_access_all_mountpoints()
> 
> ... Or something along those lines
> 

You know, I do not know.

I never understood the audit_access av perm (the part where it only
works with dontaudit te rules). All i know is that it "works" for me.

I would not consider this to be a bug. Access checks happen all over
the place, and i suppose for good reasons.