From: guido@trentalancia.net (Guido Trentalancia) Date: Fri, 30 Dec 2016 23:16:05 +0100 (CET) Subject: [refpolicy] [PATCH] init: update the initrc_t domain policy In-Reply-To: References: <1483051782.12123.10.camel@trentalancia.net> Message-ID: <219519059.71961.1483136166012.JavaMail.open-xchange@popper10.register.it> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello again. > On the 30th of December 2016 at 20.30 Chris PeBenito > wrote: > > > On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote: > > Update the initrc_t domain policy in the init module with some > > missing permissions. > > > > Signed-off-by: Guido Trentalancia > > --- > > policy/modules/kernel/terminal.if | 21 +++++++++++++++++++++ > > policy/modules/system/init.te | 19 +++++++++++++++++-- > > 2 files changed, 38 insertions(+), 2 deletions(-) [...] > > domain_kill_all_domains(initrc_t) > > domain_signal_all_domains(initrc_t) > > @@ -496,6 +502,8 @@ files_exec_etc_files(initrc_t) > > files_read_usr_files(initrc_t) > > files_manage_urandom_seed(initrc_t) > > files_manage_generic_spool(initrc_t) > > +# manage the restorecond lock file > > +files_manage_generic_locks(initrc_t) > > initrc_t can already delete all locks. Why does it need to create locks? The init scripts usually create the lock file upon starting up the service (and delete it when stopping the service). If you look at the script file restorecond.init from policycoreutils/restorecond, you'll find the following: touch /var/lock/subsys/restorecond which implies files_manage_generic_locks(initrc_t). I hope it helps... Regards, Guido