if you are looking to prevent access, you should instead be doing something like this:
chown -R nobody:nobody *.py ... etc. On Jun 11, 5:41 pm, Yarko Tymciurak <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> wrote: > > > > lock-web2py.sh is a fantastic idea! > > > > On Jun 10, 4:28 pm, mdipierro <[email protected]> wrote: > > > > > perhaps we should a web2py/scripts/lock-web2py.sh > > > > > On Jun 10, 3:49 pm, Thadeus Burgess <[email protected]> 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 <[email protected]> > > > > > 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 <[email protected]> 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.
