[refpolicy] [PATCH 5/9] Label /usr/lib/udisks/udisks-helper-* with bin_t

Guido Trentalancia guido at trentalancia.com
Sun Sep 9 07:06:27 CDT 2012


On 07/09/2012 15:12, Sven Vermeulen wrote:
> In light of the contrib split, perhaps we might want to consider
> allowing these generic types that should be on everyone"s base policy
> within the modules?
>
> On Sep 7, 2012 3:08 PM, "Christopher J. PeBenito" <cpebenito at tresys.com
> <mailto:cpebenito at tresys.com>> wrote:
>
>     On 09/04/12 17:37, Laurent Bigonville wrote:
>      > From: Laurent Bigonville <bigon at bigon.be <mailto:bigon at bigon.be>>
>      >
>      > ---
>      >  devicekit.fc |    1 +
>      >  1 file changed, 1 insertion(+)
>      >
>      > diff --git a/devicekit.fc b/devicekit.fc
>      > index 9af85c8..ae2d805 100644
>      > --- a/devicekit.fc
>      > +++ b/devicekit.fc
>      > @@ -1,4 +1,5 @@
>      >  /usr/lib/udisks/udisks-daemon        --
>       gen_context(system_u:object_r:devicekit_disk_exec_t,s0)
>      > +/usr/lib/udisks/udisks-helper-.* --
>     gen_context(system_u:object_r:bin_t,s0)
>      >
>      >  /usr/libexec/devkit-daemon   --
>       gen_context(system_u:object_r:devicekit_exec_t,s0)
>      >  /usr/libexec/devkit-disks-daemon --
>       gen_context(system_u:object_r:devicekit_disk_exec_t,s0)
>      >
>
>     This belongs in corecommands, if bin_t is appropriate.

/usr/lib/udisks for udev version 1 (such as udisks-1.0.4) helpers is not 
the standard location, as the standard location is /usr/libexec. So this 
is a customization, which should eventually be enclosed in one or more 
ifdef_distro blocks.

The standard location is the one produced by the raw execution of the 
configure script (i.e. without options passed) or otherwise (where 
autotools are not used) by an unedited Makefile (with the expection 
perhaps of default Makefiles that install in /usr/local).

When the standard location is used, the udev1 helpers are labelled as bin_t.

Finally, udev version 2 is no longer going to have the helpers.

And, all types should stick in their appropriate place, as otherwise 
they might sooner or later become unmanageable.

>     --
>     Chris PeBenito
>     Tresys Technology, LLC
>     www.tresys.com <http://www.tresys.com> | oss.tresys.com
>     <http://oss.tresys.com>

Regards,

Guido


More information about the refpolicy mailing list