glibc post upgrade

[Stephen Smalley]

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 at epoch.ncsc.mil>
National Security Agency