This would be a security concern:  I do not think you want web
executables / files owned by root.    You would then be forced to open
up accessibility to the files (so that something which _is not root_
can run / read them)  --- which would weaken security;   OR  you would
(???) need to run as root (which is _really_ dangerous, and shared
hosting providers will not allow).

On Jun 11, 5:12 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> how about this:
>
> chown -R root:root *.py
> chown -R root:root gluon
> chown -R root:root scripts
> chown -R root:root applications/*/modules/
> chown -R root:root applications/*/models/
> chown -R root:root applications/*/controllers/
> chown -R root:root applications/*/views/
> chown -R root:root applications/*/static/
> chown -R root:root applications/*/cron/
> echo "unlock with chown -R www-data:www-data ./"
>
> On Jun 11, 3:24 pm, Salvor Hardin <salvor.pub...@gmail.com> wrote:
>
>
>
> > lock-web2py.sh is a fantastic idea!
>
> > On Jun 10, 4:28 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > perhaps we should a web2py/scripts/lock-web2py.sh
>
> > > On Jun 10, 3:49 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
>
> > > > www-data needs write access to databases/cache/sessions etc. IF a
> > > > hacker were able to gain access *somehow* and alter the databases
> > > > files, they can kill your entire system by forcing fake migrations or
> > > > other issues. Just make sure you have migrate=False and
> > > > fake_migrate=False and everything *should* be just fine.
>
> > > > --
> > > > Thadeus
>
> > > > On Thu, Jun 10, 2010 at 2:01 PM, mdipierro <mdipie...@cs.depaul.edu> 
> > > > wrote:
> > > > > None of these should be a problem. Mind that you will not be able to
> > > > > edit/install/uninstall apps using the web interface.
>
> > > > > On Jun 10, 1:45 pm, Salvor Hardin <salvor.pub...@gmail.com> wrote:
> > > > >> We selected web2py over django and pylons to replace RoR.  Luckily,
> > > > >> that project doesn't require paranoid security (hence our ability to
> > > > >> use RoR in the past.)
>
> > > > >> But we're evaluating web2py to replace a Win32 GUI intranet app, and
> > > > >> preventing hacks on the server side, is pretty high on the priority
> > > > >> for that project.  For example, we want to prevent user from 
> > > > >> modifying
> > > > >> web2py's .py files, etc. by exploiting security flaws in Python or
> > > > >> python modules.
>
> > > > >> What are some ways to improve the security of web2py apps on
> > > > >> production servers?
>
> > > > >>  * Use mod_security and its Core Rule Set (no web2py compatibility
> > > > >> issues?)
>
> > > > >>  * Prevent Apache2 user (www-data) having write access or chmod 
> > > > >> rights
> > > > >> to web2py application files?
>
> > > > >>  * chown/chmod web2py files to require root access to upgrade to 
> > > > >> newer
> > > > >> web2py?
>
> > > > >> I'm not asking for changes to web2py. I'm just looking for best
> > > > >> practices on projects that value security over certain features like
> > > > >> web-based upgrades or web-based deployment, etc.  For example,
> > > > >> requiring root access to upgrade web2py would be seen as a benefit on
> > > > >> at least one project.

Reply via email to