Hi guys,
Let's say I am in the need for two interfaces.
One would do:
files_pid_filetrans($1, udev_rules_t, dir, $2)
the other one
filetrans_pattern($1, udev_var_run_t, udev_rules_t, dir, $2)
I'm a bit in doubt about what to call the interfaces.
I believe the first one would be "udev_pid_filetrans_rules_dirs" as it seems
that all *_pid_filetrans routines I find in the policy are about the
var_run_t-based file transition, but then for the second one we would have
no clear answer.
One way to tackle such cases, as Dominick Grift suggested on the chat, is to
use *_generic_pid_filetrans for all the files_pid_filetrans() interfaces
currently in the policy, but that does mean all interfaces will need to be
updated.
Then udev_generic_pid_filetrans_rules_dirs could be used for the first case,
and udev_pid_filetrans_rules_dirs for the second.
So, what's the take on this?
Wkr,
Sven Vermeulen
On 07/01/12 05:29, Sven Vermeulen wrote:
> Hi guys,
>
> Let's say I am in the need for two interfaces.
>
> One would do:
> files_pid_filetrans($1, udev_rules_t, dir, $2)
> the other one
> filetrans_pattern($1, udev_var_run_t, udev_rules_t, dir, $2)
>
> I'm a bit in doubt about what to call the interfaces.
>
> I believe the first one would be "udev_pid_filetrans_rules_dirs" as it seems
> that all *_pid_filetrans routines I find in the policy are about the
> var_run_t-based file transition, but then for the second one we would have
> no clear answer.
>
> One way to tackle such cases, as Dominick Grift suggested on the chat, is to
> use *_generic_pid_filetrans for all the files_pid_filetrans() interfaces
> currently in the policy, but that does mean all interfaces will need to be
> updated.
>
> Then udev_generic_pid_filetrans_rules_dirs could be used for the first case,
> and udev_pid_filetrans_rules_dirs for the second.
>
> So, what's the take on this?
The general idea of the naming is modulename_fromtype_filetrans[_totype], where fromtype and totype are the more abstract names for the types. But it sounds like the above situation is messy. Would you further describe what you're trying to do (raw rules would be fine)?
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Mon, Jul 02, 2012 at 08:05:38AM -0400, Christopher J. PeBenito wrote:
> On 07/01/12 05:29, Sven Vermeulen wrote:
> > Let's say I am in the need for two interfaces.
> >
> > One would do:
> > files_pid_filetrans($1, udev_rules_t, dir, $2)
> > the other one
> > filetrans_pattern($1, udev_var_run_t, udev_rules_t, dir, $2)
> >
> > I'm a bit in doubt about what to call the interfaces.
[...]
> > So, what's the take on this?
>
> The general idea of the naming is modulename_fromtype_filetrans[_totype],
> where fromtype and totype are the more abstract names for the types. But
> it sounds like the above situation is messy. Would you further describe
> what you're trying to do (raw rules would be fine)?
One is:
filetrans_pattern($1, var_run_t, udev_rules_t, dir, $2)
The other one:
filetrans_pattern($1, udev_var_run_t, udev_rules_t, dir, $2)
which is about as raw as possible without loosing the idea ;-) For instance,
an init script creates "rules.d" in "/run/udev", so we need the second one.
But udevadm creates "rules" in "/var/run" which needs the first one.
filetrans_pattern(initrc_t, udev_var_run_t, udev_rules_t, dir, "rules.d")
filetrans_pattern(udev_t, var_run_t, udev_rules_t, dir, "rules")
The problem with the naming is that, in this particular case, _fromtype_ is
dubious. By using "_pids_" it can either refer to the generic one
(var_run_t) or to the subtype of the module (udev_var_run_t).
I might work around the issue by trying to work around the question itself
(why does udevadm want to create a "rules" in /var/run, shouldn't it use
/var/run/udev) but I think that's a bit besides the point right now, as
there might be different situations where we have this case.
Wkr,
Sven Vermeulen
On 7/2/2012 4:15 PM, Sven Vermeulen wrote:
> On Mon, Jul 02, 2012 at 08:05:38AM -0400, Christopher J. PeBenito wrote:
>> On 07/01/12 05:29, Sven Vermeulen wrote:
>>> Let's say I am in the need for two interfaces.
>>>
>>> One would do:
>>> files_pid_filetrans($1, udev_rules_t, dir, $2)
>>> the other one
>>> filetrans_pattern($1, udev_var_run_t, udev_rules_t, dir, $2)
>>>
>>> I'm a bit in doubt about what to call the interfaces.
> [...]
>>> So, what's the take on this?
>>
>> The general idea of the naming is modulename_fromtype_filetrans[_totype],
>> where fromtype and totype are the more abstract names for the types. But
>> it sounds like the above situation is messy. Would you further describe
>> what you're trying to do (raw rules would be fine)?
>
> One is:
>
> filetrans_pattern($1, var_run_t, udev_rules_t, dir, $2)
>
> The other one:
>
> filetrans_pattern($1, udev_var_run_t, udev_rules_t, dir, $2)
>
> which is about as raw as possible without loosing the idea ;-) For instance,
> an init script creates "rules.d" in "/run/udev", so we need the second one.
> But udevadm creates "rules" in "/var/run" which needs the first one.
> filetrans_pattern(initrc_t, udev_var_run_t, udev_rules_t, dir, "rules.d")
> filetrans_pattern(udev_t, var_run_t, udev_rules_t, dir, "rules")
>
>
> The problem with the naming is that, in this particular case, _fromtype_ is
> dubious. By using "_pids_" it can either refer to the generic one
> (var_run_t) or to the subtype of the module (udev_var_run_t).
Right. I'd go with generic pids for var_run_t; pids would imply the udev pids.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com