During a discussion about dependencies and SELinux labeling, I noticed that
we might want to improve how we currently handle pure policy-related
dependencies.
What we want to get at, is that the installation of a SELinux policy package
results in the (re)labeling of the files of the packages it holds policy
data (well, file contexts to be exact) of.
What we currently do is a subset of that: when a package is installed, its
associated SELinux policy package is merged before the package itself, so
that Portage can correctly label the files of the package. This means both a
DEPEND (has to be installed before the package) and RDEPEND (because of
binary packages) is used.
This doesn't implement what we really need fully though: updates on the
SELinux policy do not reflect upon the labels of the packages if they are
already installed. For instance, if we would change the label of the
"emerge" command in the policy, then this label is not applied unless the
administrator rebuilds Portage, relabels Portage or relabels the file
system.
This also means that we currently abuse the Portage dependency system to
accomplish a reasonable implementation. So... why not see how we can fix
things?
It would be nice if we could only mark the dependencies are RDEPEND, and in
the policy installation phase (its pkg_postinst() method) find out what
package(s) are RDEPEND'ing on this package, and then relabel the files of
those packages.
Something like so (which we can do in the selinux-policy-2.eclass):
pkg_postinst() {
# Find all packages with this package in their RDEPEND
PKGSET=$(equery -q depends ${CATEGORY}/${PN})
for PKG in ${PKGSET};
do
rlpkg ${PKG};
done
}
This simple implementation would allow us to only use RDEPEND, and would
also relabel the files after a policy update (which we don't do now) and
also doesn't require any changes to Portage or EAPI or whatever and does not
trigger any unnecessary rebuilds...
... but (there is always a but) uses a currently optional tool (equery)
which is probably also quite slow for some users. Still, I do like this
idea as it is very simple. And I like simple. Simple is nice.
Anyone know of a way to do something similar without depending on equery (it
doesn't seem like portageq has the necessary features for this)?
Anyone know of a better approach?
Wkr,
Sven Vermeulen
we might want to improve how we currently handle pure policy-related
dependencies.
What we want to get at, is that the installation of a SELinux policy package
results in the (re)labeling of the files of the packages it holds policy
data (well, file contexts to be exact) of.
What we currently do is a subset of that: when a package is installed, its
associated SELinux policy package is merged before the package itself, so
that Portage can correctly label the files of the package. This means both a
DEPEND (has to be installed before the package) and RDEPEND (because of
binary packages) is used.
This doesn't implement what we really need fully though: updates on the
SELinux policy do not reflect upon the labels of the packages if they are
already installed. For instance, if we would change the label of the
"emerge" command in the policy, then this label is not applied unless the
administrator rebuilds Portage, relabels Portage or relabels the file
system.
This also means that we currently abuse the Portage dependency system to
accomplish a reasonable implementation. So... why not see how we can fix
things?
It would be nice if we could only mark the dependencies are RDEPEND, and in
the policy installation phase (its pkg_postinst() method) find out what
package(s) are RDEPEND'ing on this package, and then relabel the files of
those packages.
Something like so (which we can do in the selinux-policy-2.eclass):
pkg_postinst() {
# Find all packages with this package in their RDEPEND
PKGSET=$(equery -q depends ${CATEGORY}/${PN})
for PKG in ${PKGSET};
do
rlpkg ${PKG};
done
}
This simple implementation would allow us to only use RDEPEND, and would
also relabel the files after a policy update (which we don't do now) and
also doesn't require any changes to Portage or EAPI or whatever and does not
trigger any unnecessary rebuilds...
... but (there is always a but) uses a currently optional tool (equery)
which is probably also quite slow for some users. Still, I do like this
idea as it is very simple. And I like simple. Simple is nice.
Anyone know of a way to do something similar without depending on equery (it
doesn't seem like portageq has the necessary features for this)?
Anyone know of a better approach?
Wkr,
Sven Vermeulen
