| Summary: | sec-policy/selinux-squid cannot resolve name httpd_squid_script_exec_t when installing package in targeted profile. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Shawn Kovalchick <bamapookie> |
| Component: | SELinux | Assignee: | SE Linux Bugs <selinux> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | autobuilds | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Shawn Kovalchick
2015-08-12 19:39:08 UTC
Uninstalling package, rebuilding sec-policy/selinux-apache (which is a dependency), then reinstalling fixed the problem. I would resolve this, but I would like to leave it open in case this is an issue that could be handled programmatically. Anyway, I'll leave that decision to you learned scholars. (In reply to Shawn Kovalchick from comment #1) > Uninstalling package, rebuilding sec-policy/selinux-apache (which is a > dependency), then reinstalling fixed the problem. Uninstalling is probably not required, just emerge selinux-apache first then do selinux-squid. > I would resolve this, but I would like to leave it open in case this is an > issue that could be handled programmatically. Anyway, I'll leave that > decision to you learned scholars. As for why this was not automatic ... I have no idea. The ebuilds have had DEPEND="${DEPEND} sec-policy/selinux-apache " RDEPEND="${RDEPEND} sec-policy/selinux-apache " in them ever since release 2.20141203-r1 so portage *should* emerge it first. Did you only "emerge -1v selinux-squid" and hit this error or did you re-emerge all of them with: "emerge -v1 $(qlist -IC sec-policy)"? the latter will re-emerge all of them and should thus do selinux-apache before selinux-squid. I don't think the problem was with the dependency. My theory is that after switching from the strict to the targeted policy, the apache policy bits had not yet been included in whatever was needed for the squid policy to compile. (I'm referring to the semodule command in my initial comment.) So even though the apache module had been built, the semodule part had not yet run (or maybe it had failed previously and I didn't notice). Running the semodule command with squid still installed would fail. After uninstalling squid and rerunning the semodule command, the squid policy installed correctly. To answer your later question, I ran emerge -1v <<ls from /var/db/whatever/.../sec-policy>>. (I'll note that qlist line for next time). I thought it rebuilt the apache module first, but I can't be certain. I *think* that the problem is that Portage rebuilds does not honor the dependency tree in the same sense as when the dependency has not been built yet. When you change POLICY_TYPES="strict" to POLICY_TYPES="strict targeted" and then rebuild the policies, Portage will think that selinux-apache is already installed (when building selinux-squid) so does not 'push' that dependency up the tree. It'll just rebuild it as part of the large rebuild you've done. Perhaps we should update the documentation to first rebuild the dependency-sensitive ones (i.e. those that are dependencies of others). From a quick grep this would be: sec-policy/selinux-daemontools sec-policy/selinux-dbus sec-policy/selinux-inetd sec-policy/selinux-java sec-policy/selinux-kerberos sec-policy/selinux-lpd sec-policy/selinux-milter sec-policy/selinux-remotelogin sec-policy/selinux-ucspitcp sec-policy/selinux-virt sec-policy/selinux-xserver But it would be even better if this was dynamically calculated in the command. Perhaps there is even a way to trigger Portage to think the packages are not installed yet? Maybe a flag (use flag, feature flag, etc.) could be set instead of a make.conf option. If the use flag changed, the it would trigger a recompile? Also, I noticed that selinux-apache was not in your list of dependencies. |
