glibc post upgrade
Jeff Johnson
n3npq at nc.rr.com
Wed Aug 25 13:54:17 UTC 2004
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
More information about the fedora-selinux-list
mailing list