glibc post upgrade

[Jeff Johnson]

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