From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 2 Jun 2014 11:23:55 -0400
Subject: [refpolicy] [PATCH 1/1] RFC: Support initrc_t generated pid
 files with file transition
In-Reply-To: <1401384210-11405-1-git-send-email-sven.vermeulen@siphos.be>
References: <1401384210-11405-1-git-send-email-sven.vermeulen@siphos.be>
Message-ID: <538C970B.10608@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 05/29/2014 01:23 PM, Sven Vermeulen wrote:
> For some daemons, it is the init script that is responsible for creating
> the PID file of the daemon. As we do not want to update the init SELinux
> policy module for each of these situations, we need to introduce an
> interface that can be called by the SELinux policy module of the caller
> (the daemon domain).
> 
> The initial suggestion was to transform the init_daemon_run_dir
> interface, which offers a similar approach for directories in /run, into
> a class-agnostic interface. Several names have been suggested, such as
> init_script_spec_run_content or init_script_generic_run_filetrans_spec,
> but in the end init_daemon_pid_file was used.
> 
> Now the question remains if we use a single interface or stick with two.
> In other words, do we want something like this:
> 
>   init_daemon_pid_file(xdm_var_run_t, dir, "xdm")
>   init_daemon_pid_file(postgresql_var_run_t, file, "postgresql.pid")
> 
> or does it make more sense to keep the classes in the name (as the names
> already imply), like so:
> 
>   init_daemon_run_dir(xdm_var_run_t, "xdm")
>   init_daemon_pid_file(postgresql_var_run_t, "postgresql.pid")
> 
> This patch choses the latter. If not, I can easily update it to use the
> other approach, and deprecate init_daemon_run_dir in favor of
> init_daemon_pid_file.

I think we probably want the first one.  Then we wouldn't run in to problems in the future when we run across an init script, for example, that wants to create a symlink or pipe, etc.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com