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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
