Graham, you've once again made my life easier. Your solution solved
ALL my ownership/permission issues. Thank you!
My mod_wsgi directive now looks like so:
WSGIDaemonProcess user1 threads=15 user=user1 group=user1 display-name=
%{GROUP}
WSGIProcessGroup user1
WSGIApplicationGroup %{GLOBAL}
I th
On May 29, 1:07 am, Michael Ellis <[EMAIL PROTECTED]> wrote:
> Thanks, John. I found a clunky solution (see next post), but I like
> your solution better. I'm usingmod_wsgiin daemon mode, but Django
> seems to be running as 'nobody'. Here's mymod_wsgidirective in
> httpd.conf's Virtualhost section
Here's my clunky, but working, solution. In the following example, I
have solved two security issues I was experiencing: 1) the original
sorl directory permissions—now 755—and 2) the 'upload_to' folder of
the source images—also now 755.
In the following example...
Apache with mod_wsgi v2.0 (daem
Thanks, John. I found a clunky solution (see next post), but I like
your solution better. I'm using mod_wsgi in daemon mode, but Django
seems to be running as 'nobody'. Here's my mod_wsgi directive in
httpd.conf's Virtualhost section:
WSGIDaemonProcess user1 threads=15 display-name=%{GROUP}
WSGIP
Try 770 with the directory's group set to the effective group of the
Apache process. If you need to get even finer, look into mod_wsgi's
daemon mode, or FastCGI, under either of which your Django app could
run as its own user. Then you could ratchet the directory permissions
down to 700 an
I'm using sorl-thumbnails on Apache. It's working fine, except
permissions on the directory in which it writes the thumbnails — /
media/images — must be set to 777. For obvious security reasons, I'd
like to work around this somehow...or at least minimize the threat.
Any suggestions?
Thanks!
ME
--
6 matches
Mail list logo
