Stephen Smalley wrote:
On Mon, 2004-08-23 at 18:23, Jeff Johnson wrote:
Well, it's not that simple.
On a parallel, multilib install battle front, /usr/bin/{glibc,libgcc} have also been causing rpm pain.
The packaging requirements are that these packages must be installable into an empty
chroot, i.e. no /bin/sh, hence statically linked helpers.
Unfortunately, the statically linked helpers are installed on the same path, but are
platform dependent. The statically linked helpers are also quite mysterious, e.g.
this isn't the first time that the rpm_t vs. rpm_script_t has been raised.
One approach to a multilib packaging solution is to use embedded lua to avoid platform
dependent helpers that are on conflicting paths.
But that then means that embedded lua will be run as "rpm_t", not "rpm_script_t",
as this is rpm running in a nearly empty chroot.
There are no easy answers for conflicting needs. Something has to give, either selinux
policy or multilib paths.
I'm afraid I don't follow this. As long as the helper is run as a
separate program (or even the same program re-exec'd), we can transition
it to a separate domain via a prior call to setexeccon(). Policy can
simply allow entrypoint permission for the domain for any of the
possible types for such helpers.
That's the point. Lua is embedded, would be run by rpm, and no re-exec because of internal state.
73 de Jeff
