python package: pyo files

[Toshio Kuratomi]

On Wed, 2006-08-09 at 17:23 -0400, Jeremy Katz wrote:
> On Wed, 2006-08-09 at 14:14 -0700, Toshio Kuratomi wrote:
> > So why isn't SELinux allowing python to write the file or using a
> > dontaudit rule to not print an audit message for those denials?  SELinux
> > is supposed to prevent things that are unexpected from happening.
> > python is expected to attempt to write the .pyo.  (The write can still
> > fail based on file permissions as normal without logging an AVC denial,
> > right?)
> 
> Well, allowing normal users to write to /usr seems like a bad idea would
> be first on my list of "why not allow it" ;-)  
> 
That should be prevented by normal Unix file permissions ;-)

> As for having a dontaudit rule, it's difficult as you can be talking
> about *anything* written in python here.  eg, think about having foo.py
> in your homedir and just running it -- it's not going to have any
> special context to be able to dontaudit writes to user.  
> 
> And in general, if an application is trying to do that, we _do_ want to
> know so that it can be fixed, so it's not practical to dontaudit all
> attempts to write to /usr.

It sounds like SELinux isn't flexible enough to do what I wish it could
in this circumstance.  :-)

In experimenting I've found what I think is a python bug which I think
swings the argument in your favor for a different reason as well.

python -O and python -OO both generate .pyos.  However, python won't
overwrite a pyo that is already generated.  I'll have to do a bit of
googling, but I think that's a bug.  If we %ghost all the pyos and then
a system administrator runs python -OO [All sorts of python programs]
he'll end up with a large number of files without docstrings.  If some
of programs need those docstrings to operate, he'll start getting
tracebacks.  At this point, running python -O [PROGRAM] won't work
because python will reuse the existing pyo instead of creating a new one
at the reduced optimization level.  The sys admin will have to rm all
the .pyos on the system to get all his docstrings back.

By the same token, because the .pyos are not overwritten, if we
precreate the .pyos the system administrator will not be able to replace
the .pyos without first rm'ing them.  So it would make sense to include
the pyos so the system administrator can't get into a broken state
without first knowing how to fix it.

If this bug is ever fixed, though, then we could see a case where we get
AVC denials again.  We install python -O optimized pyos for foo.  The
user runs python -OO foo and suddenly python will want to overwrite
the .pyos with ones that are byte compiled at a different optimization
level.  So including the .pyos is fixing a symptom, not the cause.  A
complete solution has to come from SELinux, not from tweaks we put in
the spec file.

(BTW: In case it wasn't obvious, I think it does make sense to deprecate
the usage of %ghost with .pyos, at least for now.)

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060809/c9564c29/attachment.sig>