The recent redhat-rpm-config change and you

John Dennis jdennis at
Tue Jun 21 17:41:24 UTC 2005

On Tue, 2005-06-21 at 13:20 -0400, Peter Jones wrote:
> On Tue, 2005-06-21 at 13:06 +0200, Tomas Mraz wrote:
> > > More (much more?) work for little gain, but likely the correct solution
> > > would be to configure SELinux policy to recognize a python program
> > > trying to write a pyo file and allow that to pass.  (Coupled with %
> > > ghosting.)
> > 
> > No, that wouldn't be secure. The written .pyo file could be arbitrary
> > code which if run again for example from a different security context
> > could exploit your system even more.
> Just to be sure, is this really a problem at all?  We're not shipping
> python set up to generate the .pyc and .pyo files by default, AFAIK,
> we're merely making rpm run the .pyc's through python -O.
> So if you log in as root and run some random python program that has a
> bunch of .py's in /usr/lib/python2.4/site-packages/, that shouldn't be
> generating .pyc's and .pyo's.
> This is _just_ /usr/lib/rpm/brp-redhat running brp-python-bytecompile,
> which in turn uses python -O to make .pyc's.  It's not something at
> runtime.

I think Tomas's observation is correct. The python interpreter we ship
does attempt to generate .pyc files when it executes a .py file if its
non-existent or out of date. It can be a security issue if the .pyc
or .pyo file is malicious. It might be malicious if the .py file was
malicious, but that is less likely since .py files are installed by
root. However, if you allow any user/process to write a .pyo file for
later execution you do expose yourself malicious intent via a .pyc
or .pyo which is not derived from the source .py.
John Dennis <jdennis at>

More information about the Fedora-maintainers mailing list