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.
--
Stephen Smalley <sds@xxxxxxxxxxxxxx>
National Security Agency
