* [refpolicy] [PATCH 2/2]: cpucontrol module updates (allow CPU microcode update utility as standalone application)
@ 2012-08-24 14:02 Guido Trentalancia
2012-08-29 12:57 ` Christopher J. PeBenito
0 siblings, 1 reply; 3+ messages in thread
From: Guido Trentalancia @ 2012-08-24 14:02 UTC (permalink / raw)
To: refpolicy
cpucontrol module modification to also allow execution as a
standalone application rather than just as an init script or
from run_init (mutually exclusive tunable policy won't work
easily due to the presence of typeattributes within the init
interfaces).
Signed-off-by: Guido Trentalancia <guido@trentalancia.com>
---
policy/modules/contrib/cpucontrol.te | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -pru refpolicy-08082012-a/policy/modules/contrib/cpucontrol.te
refpolicy-08082012-b/policy/modules/contrib/cpucontrol.te
--- refpolicy-08082012-a/policy/modules/contrib/cpucontrol.te 2012-08-09
02:50:45.253581021 +0200
+++ refpolicy-08082012-b/policy/modules/contrib/cpucontrol.te 2012-08-09
02:49:56.525140236 +0200
@@ -15,7 +15,7 @@ gen_tunable(cpucontrol_can_upload_cpu_mi
type cpucontrol_t;
type cpucontrol_exec_t;
-init_system_domain(cpucontrol_t, cpucontrol_exec_t)
+init_daemon_domain(cpucontrol_t, cpucontrol_exec_t)
type cpucontrol_initrc_exec_t;
init_script_file(cpucontrol_initrc_exec_t)
^ permalink raw reply [flat|nested] 3+ messages in thread
* [refpolicy] [PATCH 2/2]: cpucontrol module updates (allow CPU microcode update utility as standalone application)
2012-08-24 14:02 [refpolicy] [PATCH 2/2]: cpucontrol module updates (allow CPU microcode update utility as standalone application) Guido Trentalancia
@ 2012-08-29 12:57 ` Christopher J. PeBenito
2012-08-29 15:10 ` Guido Trentalancia
0 siblings, 1 reply; 3+ messages in thread
From: Christopher J. PeBenito @ 2012-08-29 12:57 UTC (permalink / raw)
To: refpolicy
On 08/24/12 10:02, Guido Trentalancia wrote:
> cpucontrol module modification to also allow execution as a
> standalone application rather than just as an init script or
> from run_init (mutually exclusive tunable policy won't work
> easily due to the presence of typeattributes within the init
> interfaces).
>
> Signed-off-by: Guido Trentalancia <guido@trentalancia.com>
> ---
> policy/modules/contrib/cpucontrol.te | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -pru refpolicy-08082012-a/policy/modules/contrib/cpucontrol.te
> refpolicy-08082012-b/policy/modules/contrib/cpucontrol.te
> --- refpolicy-08082012-a/policy/modules/contrib/cpucontrol.te 2012-08-09
> 02:50:45.253581021 +0200
> +++ refpolicy-08082012-b/policy/modules/contrib/cpucontrol.te 2012-08-09
> 02:49:56.525140236 +0200
> @@ -15,7 +15,7 @@ gen_tunable(cpucontrol_can_upload_cpu_mi
>
> type cpucontrol_t;
> type cpucontrol_exec_t;
> -init_system_domain(cpucontrol_t, cpucontrol_exec_t)
> +init_daemon_domain(cpucontrol_t, cpucontrol_exec_t)
I don't understand why this is necessary. From your description, init_system_domain() is appropriate, since its for short running programs started by initrc_t.
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* [refpolicy] [PATCH 2/2]: cpucontrol module updates (allow CPU microcode update utility as standalone application)
2012-08-29 12:57 ` Christopher J. PeBenito
@ 2012-08-29 15:10 ` Guido Trentalancia
0 siblings, 0 replies; 3+ messages in thread
From: Guido Trentalancia @ 2012-08-29 15:10 UTC (permalink / raw)
To: refpolicy
On 29/08/2012 14:57, Christopher J. PeBenito wrote:
> On 08/24/12 10:02, Guido Trentalancia wrote:
>> cpucontrol module modification to also allow execution as a
>> standalone application rather than just as an init script or
>> from run_init (mutually exclusive tunable policy won't work
>> easily due to the presence of typeattributes within the init
>> interfaces).
>>
>> Signed-off-by: Guido Trentalancia <guido@trentalancia.com>
>> ---
>> policy/modules/contrib/cpucontrol.te | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff -pru refpolicy-08082012-a/policy/modules/contrib/cpucontrol.te
>> refpolicy-08082012-b/policy/modules/contrib/cpucontrol.te
>> --- refpolicy-08082012-a/policy/modules/contrib/cpucontrol.te 2012-08-09
>> 02:50:45.253581021 +0200
>> +++ refpolicy-08082012-b/policy/modules/contrib/cpucontrol.te 2012-08-09
>> 02:49:56.525140236 +0200
>> @@ -15,7 +15,7 @@ gen_tunable(cpucontrol_can_upload_cpu_mi
>>
>> type cpucontrol_t;
>> type cpucontrol_exec_t;
>> -init_system_domain(cpucontrol_t, cpucontrol_exec_t)
>> +init_daemon_domain(cpucontrol_t, cpucontrol_exec_t)
>
> I don't understand why this is necessary. From your description, init_system_domain() is appropriate, since its for short running programs started by initrc_t.
You are actually right. This is not necessary.
It is not supposed to be executed as a standalone application. If it
needs to be executed anytime after system-startup, it shall still be
executed through run_init.
Thanks for pointing it out.
Best regards,
Guido
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-08-29 15:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-24 14:02 [refpolicy] [PATCH 2/2]: cpucontrol module updates (allow CPU microcode update utility as standalone application) Guido Trentalancia
2012-08-29 12:57 ` Christopher J. PeBenito
2012-08-29 15:10 ` Guido Trentalancia
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.