glibc post upgrade

Jeff Johnson n3npq at nc.rr.com
Mon Aug 23 22:23:10 UTC 2004


Daniel J Walsh wrote:

> Stephen Smalley wrote:
>
>> On Mon, 2004-08-23 at 12:56, Jeff Johnson wrote:
>>  
>>
>>> Yes, rpm_script_t is applied only for /bin/sh, not for other helpers 
>>> like /sbin/ldconfig, and
>>> /usr/sbin/{glibc,libgcc}_post_upgrade, to name the other known helpers.
>>>
>>> I can certainly change that behavior, and have asked several times 
>>> if I should, with no answer.
>>>   
>>
>>
>> I think it should change.  For now, I'd say just use rpm_script_t for
>> all commands executed from the scriptlets specified in the spec file,
>> whether run via an interpreter or as a direct executable.  Note that on
>> the policy side, the domain_trans(rpm_t, shell_exec_t, rpm_script_t)
>> rule should be changed to include any of the possible entrypoint 
>> types. However, it should work even without that change in the Fedora 
>> policy,
>> because the unlimitedRPM tunable is enabled by default.
>>
>>  
>>
> I agree, make the change.


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.

73 de Jeff

>
> Dan
> -- 
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-selinux-list
>





More information about the selinux mailing list