1 |
On Mon, Dec 05, 2011 at 08:54:13AM +0100, "Paweł Hajdan, Jr." wrote: |
2 |
> > In Gentoo, unlike some other distributions, we try to keep the number of |
3 |
> > loaded/installed modules to a minimum so that policy rebuilds as well as the |
4 |
> > system overhead is limited. This results in a "base" policy (provided by |
5 |
> > selinux-base-policy) and modules (provided by sec-policy/selinux-<modulename>). To make |
6 |
> > sure that installations of a package pull in the right SELinux module, the |
7 |
> > proper dependencies must be defined. |
8 |
> |
9 |
> Are you sure this is right choice? It seems to me that it'd be better to |
10 |
> focus no making things work, and increasing the complexity of the deps |
11 |
> makes this harder (and increasing the number of packages you maintain |
12 |
> too). Unless you have _abundant_ resources to deal with that, I'd like |
13 |
> to discourage you from handling policies that way. |
14 |
|
15 |
For end users, this is much more enjoyable. If we load up all policies, then |
16 |
any interaction with the SELinux policies will take some time. Also, all |
17 |
policies in memory do take up some space. Finally, for development purposes, |
18 |
this is very much enjoyable as well, since it allows for much faster policy |
19 |
development (rebuild policies in seconds to minutes rather than dozen of |
20 |
minutes). |
21 |
|
22 |
Maintenance is actually pretty easy. The eclass we use provides us with a |
23 |
very easy interface to add modules, and because it is a module per ebuild, |
24 |
we can push changes on individual modules without pushing full policy builds |
25 |
again. |
26 |
|
27 |
> Furthermore, imagine I'm adding a new package "foo" that is covered by |
28 |
> the SELinux policy. Most developers don't use SELinux (hey, I suspect |
29 |
> most of them don't even use developer profile; bad, bad!). How do I know |
30 |
> whether it's sec-policy/selinux-foo that's not yet added or |
31 |
> sec-policy/selinux-games or something else... If the complete policy is |
32 |
> in one package, this should be obvious, and we don't even need deps for |
33 |
> that. |
34 |
|
35 |
I know. This is one major hurdle that we need to take on. Using dependencies |
36 |
is the "easiest" approach, albeit the most resource intensive one |
37 |
(initially, that is). I don't mind having the dependencies added as we go. |
38 |
For our end users, we already documented that missing modules are to be |
39 |
expected and how to resolve it. |
40 |
|
41 |
> As said by other devs here, I also think it'd be more effective if you |
42 |
> just do the change yourself. USE="selinux" doesn't affect anything else |
43 |
> so it's safe. |
44 |
|
45 |
Ok, no problem. I'll check on IRC regardless, if not just to give a "heads |
46 |
up" on changes. |
47 |
|
48 |
Also, my apologies for not sorting the list. Careful readers will notice it |
49 |
is sorted, but by the package name, not category :/ |
50 |
|
51 |
Thanks you all for the feedback! |
52 |
|
53 |
Wkr, |
54 |
Sven Vermeulen |