Re: lame/libxvidcore & execstack

[Axel Thimm]

On Tue, May 02, 2006 at 03:09:03PM -0400, Daniel J Walsh wrote:
>  Axel Thimm wrote:
>  >On Tue, May 02, 2006 at 02:27:24PM -0400, John Griffiths wrote:
>  >  
>  >>Axel Thimm wrote:
>  >>    
>  >>>On Tue, May 02, 2006 at 02:07:37PM -0400, John Griffiths wrote:
>  >>>      
>  >>>>Daniel J Walsh wrote:
>  >>>>        
>  >>>>>John Griffiths wrote:
>  >>>>>          
>  >>>>>>fedora-selinux-list-request(a)redhat.com wrote:
>  >>>>>>            
>  >>>>>>>Subject:
>  >>>>>>>Error running ffmpeg due to permission denied on library
>  >>>>>>>From:
>  >>>>>>>"Robert Foster"
> <rfoster(a)mountainvisions.com.au&gt;
>  >>>>>>>Date:
>  >>>>>>>Thu, 27 Apr 2006 12:41:09 +1000
>  >>>>>>>To:
>  &gt;&gt;&gt;&gt;&gt;&gt;&gt;&lt;fedora-selinux-list(a)redhat.com&gt;
>  >>>>>>>
>  >>>>>>>To:
>  &gt;&gt;&gt;&gt;&gt;&gt;&gt;&lt;fedora-selinux-list(a)redhat.com&gt;
>  >>>>>>>I'm trying to get ffmpeg working for Gallery2 on FC5, and
> getting 
>  >>>>>>>the following error (from the debug message via Gallery):
>  >>>>>>>              
>  >
>  >  
>  >>>>>>I had the same problem when using Kino which also uses ffmpeg.
> Here 
>  >>>>>>is what I did and it works.
>  >>>>>>
>  >>>>>> execstack -c /usr/lib/libmp3lame.so.0
>  >>>>>> execstack -c /usr/lib/libxvidcore.so.4
>  >>>>>>       
>  >>>>>>            
>  >>>>>Please submit bugs on these to Kino and ffmpeg.
>  >>>>>     
>  >>>>>          
>  >>>>Actually /usr/lib/libmp3lame.so.0 is part of lame-3.96.1-10.rhfc5.at 
>  >>>>and libxvidcore4-1.1.0-8.rhfc5.at both from ATRpms.net.
>  >>>>
>  >>>>I'll let the people at ATRpm know.
>  >>>>        
>  >>>Is this considered a packaging or upstream issue?
>  >>>
>  >>>If packaging: What is the recommended way to fix it specfile-wise?
>  >>> 
>  >>>      
>  >>From this, I find the folks at ATRpms know.
>  >>    
>  >
>  >I'm very sure they'll be just as confused as I am ;)
>  >  
>  
>  Point them at 
        ^^^^

Them is largely myself, that's why I can tell how confused "they" will
be. ;)

>  http://people.redhat.com/~drepper/selinux-mem.html
>  
>  and
>  
>  http://people.redhat.com/drepper/nonselsec.pdf 
But these reference upstream fixing, not packaging ones. Do idioms
exist to cirumvent this at the packaging level (other than fixing the
source and Patch0: the fix), or is the recommendation to report to
upstream and wait for a fix while disabling selinux at the mean time?
-- 
Axel.Thimm at ATrpms.net