1 |
During a discussion about dependencies and SELinux labeling, I noticed that |
2 |
we might want to improve how we currently handle pure policy-related |
3 |
dependencies. |
4 |
|
5 |
What we want to get at, is that the installation of a SELinux policy package |
6 |
results in the (re)labeling of the files of the packages it holds policy |
7 |
data (well, file contexts to be exact) of. |
8 |
|
9 |
What we currently do is a subset of that: when a package is installed, its |
10 |
associated SELinux policy package is merged before the package itself, so |
11 |
that Portage can correctly label the files of the package. This means both a |
12 |
DEPEND (has to be installed before the package) and RDEPEND (because of |
13 |
binary packages) is used. |
14 |
|
15 |
This doesn't implement what we really need fully though: updates on the |
16 |
SELinux policy do not reflect upon the labels of the packages if they are |
17 |
already installed. For instance, if we would change the label of the |
18 |
"emerge" command in the policy, then this label is not applied unless the |
19 |
administrator rebuilds Portage, relabels Portage or relabels the file |
20 |
system. |
21 |
|
22 |
This also means that we currently abuse the Portage dependency system to |
23 |
accomplish a reasonable implementation. So... why not see how we can fix |
24 |
things? |
25 |
|
26 |
It would be nice if we could only mark the dependencies are RDEPEND, and in |
27 |
the policy installation phase (its pkg_postinst() method) find out what |
28 |
package(s) are RDEPEND'ing on this package, and then relabel the files of |
29 |
those packages. |
30 |
|
31 |
Something like so (which we can do in the selinux-policy-2.eclass): |
32 |
|
33 |
pkg_postinst() { |
34 |
# Find all packages with this package in their RDEPEND |
35 |
PKGSET=$(equery -q depends ${CATEGORY}/${PN}) |
36 |
for PKG in ${PKGSET}; |
37 |
do |
38 |
rlpkg ${PKG}; |
39 |
done |
40 |
} |
41 |
|
42 |
This simple implementation would allow us to only use RDEPEND, and would |
43 |
also relabel the files after a policy update (which we don't do now) and |
44 |
also doesn't require any changes to Portage or EAPI or whatever and does not |
45 |
trigger any unnecessary rebuilds... |
46 |
|
47 |
... but (there is always a but) uses a currently optional tool (equery) |
48 |
which is probably also quite slow for some users. Still, I do like this |
49 |
idea as it is very simple. And I like simple. Simple is nice. |
50 |
|
51 |
Anyone know of a way to do something similar without depending on equery (it |
52 |
doesn't seem like portageq has the necessary features for this)? |
53 |
|
54 |
Anyone know of a better approach? |
55 |
|
56 |
Wkr, |
57 |
Sven Vermeulen |