-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Please Review and Ack.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8HL0YACgkQrlYvE4MpobPalACg3wa0LjXt9EKmwkoNLtRmwGGf
5CcAn2cp4qyKv1LT69sw8fYMGCk9ptC1
=fK7b
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctdbd.patch
Type: text/x-patch
Size: 9288 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20120106/8073c240/attachment.bin
On Fri, Jan 06, 2012 at 12:28:38PM -0500, Daniel J Walsh wrote:
> Please Review and Ack.
[...]
There's some indentation wrong (especially in the interfaces), looks like
there are some lines with tab and some with spaces.
> +exec_files_pattern(ctdbd_t, ctdbd_var_lib_t, ctdbd_var_lib_t)
Oh noes, not again ;-)
Same here like with boinc, is there a possibility to have some segregation
between the "regular" ctdbd_var_lib_t and the files ctdbd_t wants to
execute?
If not (or not feasible), ok by me.
Wkr,
Sven Vermeulen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/09/2012 04:08 PM, Sven Vermeulen wrote:
> On Fri, Jan 06, 2012 at 12:28:38PM -0500, Daniel J Walsh wrote:
>> Please Review and Ack.
> [...]
>
> There's some indentation wrong (especially in the interfaces),
> looks like there are some lines with tab and some with spaces.
>
>> +exec_files_pattern(ctdbd_t, ctdbd_var_lib_t, ctdbd_var_lib_t)
>
> Oh noes, not again ;-)
>
> Same here like with boinc, is there a possibility to have some
> segregation between the "regular" ctdbd_var_lib_t and the files
> ctdbd_t wants to execute?
>
> If not (or not feasible), ok by me.
>
> Wkr, Sven Vermeulen
> _______________________________________________ refpolicy mailing
> list refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
Maybe if these have a constant name, but we have to ask Miroslav.
Maybe we could use file_name_trans rules, but I still think we end up
with a type that has to be written and executed by the same domain.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8LWp4ACgkQrlYvE4MpobMnBwCg4/1K8+VHObTlWePkrRupWaeV
tUoAoKnyvJV2W8i7tXNrwq7exIKF3X1A
=cEv+
-----END PGP SIGNATURE-----
On Mon, Jan 09, 2012 at 04:22:38PM -0500, Daniel J Walsh wrote:
> > Same here like with boinc, is there a possibility to have some
> > segregation between the "regular" ctdbd_var_lib_t and the files
> > ctdbd_t wants to execute?
>
> Maybe if these have a constant name, but we have to ask Miroslav.
> Maybe we could use file_name_trans rules, but I still think we end up
> with a type that has to be written and executed by the same domain.
It's a bit odd that it's the "generic" _var_lib_t domain for this purpose.
It gives users a different impression (I don't imagine that any *_var_lib_t
is executed by its "parent" domain).
$ sesearch -c file -p write -A | grep execute | grep var_lib
allow xserver_t xkb_var_lib_t : file { write ... execute execute_no_trans } ;
That's the only one on my system where a domain has both write and execute
rights to a _var_lib_t type. When I'm aware of a domain writing and executing
files (because its "flexible" that way) I always hope that this results in a
separate domain (like with boic) or that it isn't for a wide type.
Of course, there are plenty of examples out there where this doesn't hold up
(like logrotate_t having write/execute rights for logrotate_tmp_t) so I'm
not /against/ these policies (boinc and ctdbd), just careful.
Wkr,
Sven Vermeulen