From: guido@trentalancia.com (Guido Trentalancia)
Date: Fri, 18 Mar 2011 23:53:00 +0100
Subject: [refpolicy] mtab lock files label (was [patch 1/3] Implementation
 of system conf type)
In-Reply-To: <4D70F55D.5000405@tresys.com>
References: <4D5E95C1.9080805@redhat.com>  <20110219095711.GA6270@siphos.be>
	<1298180267.3098.11.camel@tesla.lan>  <4D62875A.8060006@redhat.com>
	<1298319075.11119.3.camel@tesla.lan>  <4D63DA61.3050705@tresys.com>
	<1298391526.16004.8.camel@tesla.lan>  <4D6D4FBA.5040005@tresys.com>
	<1299012069.14035.36.camel@tesla.lan>  <4D6E5523.7040001@tresys.com>
	<1299163002.19257.15.camel@tesla.lan>  <4D70F55D.5000405@tresys.com>
Message-ID: <1300488781.5246.5.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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