All of lore.kernel.org
 help / color / mirror / Atom feed
From: sven.vermeulen@siphos.be (Sven Vermeulen)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Transition of files and directories created by initscript
Date: Thu, 29 Nov 2012 18:49:24 +0100	[thread overview]
Message-ID: <20121129174841.GA14171@siphos.be> (raw)
In-Reply-To: <20121129180321.6a62fa6f@soldur.bigon.be>

On Thu, Nov 29, 2012 at 06:03:21PM +0100, Laurent Bigonville wrote:
> Currently there is the init_daemon_run_dir() interface that allows to
> transition directories in the correct context. Dominick has suggested me
> on IRC create a new interface to generalize to transition files
> (something like init_pid_initrc_spec_filetrans()).

Why not add in an init_daemon_run_file() interface?

It's perhaps a very personal opinion, but I find it easier to read:

  type mysqld_var_run_t;
  files_pid_file(mysqld_var_run_t)
  init_daemon_run_dir(mysqld_var_run_t, "mysqld")

versus

  type mysqld_var_run_t;
  files_pid_file(mysqld_var_run_t)
  init_pid_initrc_spec_filetrans(mysqld_var_run_t, dir, "mysqld")

The _spec_ always throws me off, as spec_domtrans_pattern is to imply that
the domain itself is SELinux-aware and will specify a transition itself. For
a spec_filetrans, I would expect the same behavior (i.e. no automatic file
transition, but the domain itself is SELinux-aware and choses a new file
type) - only it doesn't make sense, since for file transitions, no
policy-wise rules are needed (just allow the domain write to the parent type
and create for the target type + relabel rights?)

Wkr,
	Sven Vermeulen

  parent reply	other threads:[~2012-11-29 17:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-29 17:03 [refpolicy] Transition of files and directories created by initscript Laurent Bigonville
2012-11-29 17:22 ` grift
2012-11-29 17:49 ` Sven Vermeulen [this message]
2012-11-29 17:58   ` grift

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121129174841.GA14171@siphos.be \
    --to=sven.vermeulen@siphos.be \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.