Hello, I noticed that Django-1.3 has spent 14 days in the testing branch as of yesterday - do you plan to release it now, or does additional testing need to be done on it?
Thanks, Adam Bishop Access & Identity Management Janet Direct line: +44 (0)1235 822 245 Janet, the UK’s education and research network On 20 Apr 2012, at 19:25, David Malcolm wrote: > On Fri, 2012-04-20 at 09:37 -0700, Toshio Kuratomi wrote: >> On Fri, Apr 20, 2012 at 12:16:34PM -0400, Adam Young wrote: >>> On 04/20/2012 10:47 AM, Toshio Kuratomi wrote: >>> >>> On Fri, Apr 20, 2012 at 09:42:26AM -0400, Adam Young wrote: >>> >>> One caveat. Any DJango app (Probably most Python wsgi apps, >>> actually) is >>> going to give an AVC Denial warning upon startup. >>> >>> Only a denial? ;-) Do you have selinux in permissive? >>> >>> In enforcing it still gives a denial.... >>> DJango imports Python's UUID >>> module which in turn imports ctypes. Ctypes does dynamic code >>> generation, >>> specifically by writing a file andd then trying to execute it, >>> which, as you >>> can imagine, is a pretty big security hole. Let the wsgi community >>> know that, >>> until we have that fixed, we should not attempt to get rid of the >>> AVC denial >>> warning message, but instead should push on the Python upstread to >>> get a fix >>> in. Yes, David Malcolm is aware of it. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=814391 >>> >>> >>> That's sorta a duplicate of this bug; >>> https://bugzilla.redhat.com/show_bug.cgi?id=582009 >>> >>> (AFAICS, they're the same, but yours is against RHEL and mine is against >>> Fedora). >>> >>> >>> Yes, they are the same, but mine has to do with the fact that it is part >>> of >>> the core library calling into ctypes. They can be addressed and fixed >>> separately. >>> >> Upstream python doesn't like ctypes because it allows python code to more >> easily create obscure bugs but it likes it more than the alternatives. The >> reason is that upstream python is very friendly to the alternate language >> vms/interpreters. Those alternatives often can't work with the python >> C-API/ABI. But they can work with ctypes. >> >>> >>> I discussed it with dmalcolm when I opened it in 2010 -- it's not easily >>> solvable. >>> >>> * By its nature, libffi needs to generate code that it then executes. >>> >>> I think this is the crux of the matter. I do not think that libffi needs to >>> write this code out to disk to read it back in. It would be better if it >>> held >>> it in memory, but even that would probably be disallowed by SELinux. I >>> suspect >>> that there are better ways to do this form of dynamic binding that does not >>> require code generation. >>> >> The previous python maintainer actually wrote the patch to have it write out >> to disk because we have SELinux set to prevent execmem by default. Writing >> to disk is "better" in that it allows noexecmem by default on Fedora. >> >>> However, for libraries shipped with Fedora, there should be no need to use >>> ctypes. >>> >> If you're talking about changing uuid into an extension module, then see >> above as to why that isn't an upstreamable change. > > It may be possible to fix the issue with uuid with a one-line change to > ctypes which makes it avoid the SELinux-unfriendly codepaths unless > absolutely necessary (uuid doesn't use them): see > https://bugzilla.redhat.com/show_bug.cgi?id=814391#c2 > > > _______________________________________________ > epel-devel-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/epel-devel-list Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
