On Wed, Feb 10, 2016 at 10:57:29AM -0800, James Schneider wrote: > On Wed, Feb 10, 2016 at 7:15 AM, Fred Stluka <f...@bristle.com> wrote: > > > On 2/10/16 4:37 AM, James Schneider wrote: > > > > ... make sure that the Apache system user has read access to that > > directory and all subdirectories, and no write access ... > > > > James, > > > > Won't that prevent Django from creating *.pyc files from the > > deployed *.py files? Or do you suggest deploying *.pyc files? > > > > --Fred > > > > Oh, yep, you're right. It was 1:30am and I was in PHP mode in my head (I'm > not getting kicked off the list for mentioning that word, right? ;-D). I > believe that means that the Apache user needs write access to the project > folders (to create the .pyc files), but still only needs read access to the > .py files. I believe that you can tweak the write access to the .pyc files > and parent folders after they have been generated by mod_wsgi/Apache. You > can also do a deployment just using just the .pyc files, if I remember > correctly. > > Thanks for the double-check. > > -James
I'm not entirely convinced this is the best idea, to be honest. Sure, it might be possible, but I fail to see the benefit you get out of that, compared to just granting the apache user full write access. If the user has read-only access to *.py files, but read-write access to *.py[co], a hypothetical attacker with the ability to write to arbitrary files in your filesystem could just write bytecode directly to the bytecode files instead of writing plaintext to sources, with the same effect (which is arbitrary code execution). The only benefit you get out of it is a much more complicated set of permissions on your files that will make your life harder to set up correctly, and easy to mess up, thus potentially breaking the application in subtle ways. (Unless, of course, there's some scenario that I'm overlooking, which is perfectly possible.) I see several options: * You can decide you don't need the startup speed benefits of having pre-compiled bytecode files, just deploy read-only source files. As long as your application server (mod_wsgi?) runs in long-lived processes, the bytecode files only really play any role on startup, when everything gets imported, and might make the difference of, I don't know, a second, tops (unless you have *really* many Python modules that get imported on startup – take this as a very rough estimate, and try to measure the difference for yourself instead of taking my word for it). If that delay is acceptable to you, just ignore bytecode files. * You could generate bytecode files beforehand as part of your deployment infrastructure (for example when generating the package you install on your servers), and install them read-only along with the plaintext source files. For example, if you use pip to install your application on your servers, it will create *.pyc files automatically with the --compile flag [1]. * You could decide that creating this particular layer of defense against an attacker with the ability to write to arbitrary files is not worth it, and just go full read-write. It really depends on the security requirements and trade-offs you're willing to accept. In one project, we're going with the second option, where we build DEB/RPM packages, and include all bytecode files inside those packages, only writable by root, while the application runs as a separate user. In other projects we just create a separate user for every application we deploy, and run those applications from those users' home directories (where they are checked out from their git repositories). Cheers, Michal [1]: https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption--compile -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20160210200258.GI2245%40koniiiik.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
