Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 71566 invoked from network); 3 Feb 2011 20:24:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Feb 2011 20:24:10 -0000 Received: (qmail 35534 invoked by uid 500); 3 Feb 2011 20:24:07 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 35462 invoked by uid 500); 3 Feb 2011 20:24:07 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 35454 invoked by uid 99); 3 Feb 2011 20:24:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Feb 2011 20:24:06 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.213.45] (HELO mail-yw0-f45.google.com) (209.85.213.45) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Feb 2011 20:24:02 +0000 Received: by ywa8 with SMTP id 8so783688ywa.18 for ; Thu, 03 Feb 2011 12:23:41 -0800 (PST) Received: by 10.236.110.162 with SMTP id u22mr22451185yhg.51.1296764620804; Thu, 03 Feb 2011 12:23:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.109.16 with HTTP; Thu, 3 Feb 2011 12:23:00 -0800 (PST) In-Reply-To: <139438.31556.qm@web95619.mail.in.yahoo.com> References: <139438.31556.qm@web95619.mail.in.yahoo.com> From: Scott Gifford Date: Thu, 3 Feb 2011 15:23:00 -0500 Message-ID: To: users@httpd.apache.org Content-Type: multipart/alternative; boundary=0023547c8c9b94942c049b668a50 Subject: Re: [users@httpd] giving write permissions to apache user on some folders in document root --0023547c8c9b94942c049b668a50 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 3, 2011 at 2:48 PM, James Godrej wrote: [ ... ] > I am not at all convinced by the idea of giving permissions to read,write > and > execute as these Learning Management Systems say. > Let me know what you people have to say? > What is the best practise in such situations? > James, You are right that making these directories writable by the Web server or world-writable increases your security risk, since in many cases it allows escalating the ability to write to the filesystem to the ability to execute arbitrary code as your Web server user. One option for mitigating this is to carefully configure the Apache-writable directories so they will not execute content, by limiting the types of content allowed there, disabling CGI execution, making sure .htaccess files are ignored, etc. Generally the content of these directories will be static images and so won't need to be executed. You may find you are able to run the content-management part of the system using a different Apache instance than the user-viewable part. That would let you make these directories writable by the admin Apache instance but not the public one, then protect that Apache instance with firewall rules, a strong password, SSL, etc. This would most likely require a bit of work. Finally, you can carefully review the security of these applications, their history of security incidents, etc. to determine if they are reliable enough to be trusted with this sort of access. If not, try to find one that is. Sorry there are no simple answers there, but hopefully it is helpful. ------Scott. --0023547c8c9b94942c049b668a50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Feb 3, 2011 at 2:48 PM, James Godrej <jamesgodrej@yahoo.in> wrote:=
[ ... ]
I am not at all convinced by the idea of giving permissions to read,write a= nd
execute as these Learning Management Systems say.
Let me know what you people have to say?
What is the best practise in such situations?

James,

You are right that making these dire= ctories writable by the Web server or world-writable increases your securit= y risk, since in many cases it allows escalating the ability to write to th= e filesystem to the ability to execute arbitrary code as your Web server us= er.

One option for mitigating this is to carefully configur= e the Apache-writable directories so they will not execute content, by limi= ting the types of content allowed there, disabling CGI execution, making su= re .htaccess files are ignored, etc. =A0Generally the content of these dire= ctories will be static images and so won't need to be executed.

You may find you are able to run the content-management= part of the system using a different Apache instance than the user-viewabl= e part. =A0That would let you make these directories writable by the admin = Apache instance but not the public one, then protect that Apache instance w= ith firewall rules, a strong password, SSL, etc. =A0This would most likely = require a bit of work.

Finally, you can carefully review the security of these= applications, their history of security incidents, etc. to determine if th= ey are reliable enough to be trusted with this sort of access. =A0If not, t= ry to find one that is.

Sorry there are no simple answers there, but hopefully = it is helpful.

------Scott.

--0023547c8c9b94942c049b668a50--