From: jason@perfinion.com (Jason Zaman)
Date: Thu, 31 Jul 2014 00:57:34 +0400
Subject: [refpolicy] RFC: Supporting tmpfiles policy-wise
In-Reply-To: <53D93C7D.4050101@tresys.com>
References: <20140729161202.GA12297@siphos.be>
 <53D93C7D.4050101@tresys.com>
Message-ID: <20140730205715.GA27551@pippin.Home>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Wed, Jul 30, 2014 at 02:42:05PM -0400, Christopher J. PeBenito wrote:
> On 7/29/2014 12:12 PM, Sven Vermeulen wrote:
> > I'd like to hear from you about the following - given the discussion on this
> > list earlier, I think the approach below is the best. Putting tmpfiles in
> > the not-yet-available systemd policy might not be the best approach, as
> > tmpfiles support will be needed in other init systems as well as upstream
> > projects start supporting tmpfiles.d/*.conf.
> > 
> > The tmpfiles application, as documented in [1], is used to prepare directory
> > structures in runtime, volatile locations (such as /var/run, /run and
> > perhaps even /tmp and /var/tmp).
> > 
> > [1] http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
> [...]
> > In my humble opinion, this is a full-fledged application with a defined
> > interface for administrators, and with specific privileges (creating &
> > deleting resources all around the place). I think the best approach here
> > would be to create a separate tmpfiles module, which
> 
> I agree that it should be its own module.
> 
> > - defines the (a.) directory as tmpfiles_usr_lib_t
> > - defines the (b.) directory as tmpfiles_var_run_t
> > - defines the (c.) directory as tmpfiles_conf_t
> > - creates a tmpfiles_t domain that has
> > -- read privileges on tmpfiles_{usr_lib,var_run,conf}_t
> > -- create+write+delete privileges on pidfiles, device_t,
> >    device_node, tmp_t and so forth (cfr [1] documentation)
> > -- capability to set labels on all resources
> > - introduce the proper interface(s) to allow other domains to interact with
> >   the defined resource types
> [...]
> > As tmpfiles is SELinux-aware and performs restorecon (or similar) internally
> > on the generated resources (at least from looking at the code, that is) we
> > don't need to include many file transitions, instead make sure that the
> > domain is capable of setting contexts.
> 
> If it's SELinux-aware, why doesn't it setfscreatecon() instead of
> relabeling?

tmpfiles does not always create the dir, if it already exists it just
relabels. It can sometimes also be used to clear out a dir and such
things.

-- Jason