From: russell@coker.com.au (Russell Coker)
Date: Sun, 5 Mar 2017 15:41:06 +1100
Subject: [refpolicy] [PATCH] systemd-nspawn
In-Reply-To: <20170304122634.GA3913@t450.enp8s0.d30>
References: <20170228110557.ck7x4ligazrhdnrx@athena.coker.com.au>
	<0ae32e3a-4447-62fc-736a-19e5db03ff44@ieee.org>
	<20170304122634.GA3913@t450.enp8s0.d30>
Message-ID: <201703051541.06781.russell@coker.com.au>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Sat, 4 Mar 2017 11:26:34 PM Dominick Grift via refpolicy wrote:
> > > We need to fix this /run vs /var/run thing.  We need one canonical name
> > > and we need to change everything to it.  Chris, you want me to write a
> > > patch to change everything to /run?
> 
> That might cause issues. SELinux aware programs will use matchpathcon
> similar functionality to look up the context of the to be created files
> They will end up thinking that file needs to be labeled var_t because they
> still look up using the /var/run path

That seems unlikely as it seems that most instances have already been changed.  
I just sent the patch to the list and it was surprisingly small.

Applications should use the canonical name which has been /run for some years 
now.  We can have the subst entry in the upstream policy for a while to cater 
for this, but in the long term it should be removed.  If there are any apps 
that do such lookups with /var/run then I think the correct thing to do is to 
have duplicate file_contexts entries for those few files rather than having a 
subst entry for the entire system.  This means we know which things need to be 
fixed.

I'm going to remove that subst entry in the Debian policy regardless of what 
is done upstream.  I'll make Debian work correctly with /run.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/