[refpolicy] mtab lock files label (was [patch 1/3] Implementation of system conf type)

[guido@trentalancia.com (Guido Trentalancia)]

On Fri, 04/03/2011 at 09.21 -0500, Christopher J. PeBenito wrote:
> > I also take the opportunity to remind you of the issue with mtab
> lock
> > files that I had already mentioned a few days ago.
> > 
> > Basically, mount tries to create lock files named:
> > 
> > /etc/mtab~<pid>
> > 
> > where <pid> gets substituted with the process id of mount itself.
> > 
> > Unfortunately at the moment these files are currently falling back
> to
> > the etc_t label. It is very much desirable to have them labeled
> > etc_runtime_t to avoid problems (denials) with write operations.
> > 
> > Originally the name for those lock files was /etc/mtab~. To avoid
> race
> > conditions it was decided to append the <pid>. The source code is
> > designed so that the upper bound for the length of <pid> is 20.
> > 
> > Please note that contrary to what is stated in the source code for
> mount
> > (fstab.c) there is no dot between "/etc/mtab~" and "<pid>" (it's not
> > "/etc/mtab~.<pid>") !
> > 
> > Can somebody please take care of this ?
> 
> I don't see why this would be happening.  There are the following
> rules
> in mount:
> 
> files_manage_etc_runtime_files(mount_t)
> files_etc_filetrans_etc_runtime(mount_t, file)
> 
> So the file should be created with etc_runtime_t.  The only reasons I
> can think of this mtab~<pid> file having etc_t are
> 
> 1. it was there already and someone did a relabel

Explained. /etc/mtab* easily ends up in restorecond.conf (it's even in
selinuxproject.org). Now to me the incorrect etc_t type for mtab lock
files looks as a bug in the file contexts definitions that should be
fixed.

> 2. some new SELinux logic in it that does a matchpathcon on the
> filename
> and then does setfscreatecon() to that context.
> 
> So if either of those is the case, you could add a file context entry
> to
> try to fix it.

Regards,

Guido