Django user shouldn't have sudo

[btbonval]

We need to rethink some of the security design in deployed systems.

Apache, when running mod_python or mod_wsgi, will drop user privileges intelligently.

Nginx runs as root, but it also drops user privileges as needed. It does not run the software, but rather reverse proxies it from Django.

I think we have no reason to trust python manage.py runserver. Django isn't an application I would trust with unix-level security.

We need sudo for a number of first_deploy activities. We could do two things:

1. the user is given sudo for those commmands, then sudo is revoked
2. we rewrite the fab file with the assumption that the executing user is not necessarily the Django user (this shouldn't be hard).

[btbonval]

In previous work, I had a sudo user and a target user. Fabric's with prefix against sudo su - user to switch to the target user, which works as long as the fabric user has sudo privs.

If both the target and sudo user are the same, there can be a quick check for that which basically ignores the with prefix check. This logic would go in a function like def run_as(user, command).

[btbonval]

Actually, by supporting two users (one with sudo, one the django user), we automatically support fabric commands on staging and prod systems. Presently one would need SSH access to the django user to facilitate fab commands directly to staging/prod, which we'd rather not do. Whereas the main devvers do have SSH access to users with sudo on those machines.

[btbonval]

This was an interesting problem, but as we now run on Heroku, it no longer affects the KarmaNote servers. We no longer have deployed servers where the django user security can present a security problem.

Heroku sandboxes all the servers, thankfully.