delay root requirement

[ThomasWaldmann]

currently, the code checks rather early for running as uid 0 and terminates letsencrypt if it is not running as root.

this code should be put in a function "require_root" (or so) and calls to that should be put at all places where it is clear that it can't continue without root.

see also #200 - that does not require root (in fact, it doesn't require much at all, except being able to modify DNS somehow).

[jdkasten]

Yes, I was kind of waiting for a reason to implement this and have been thinking about it for quite some time.

A lot of time will need to be spent analyzing the attack surface as it becomes much harder ensure a safe operating environment when you are running as root and the client's previously generated files aren't necessarily protected.... or you are running as a normal user and you don't have permission to edit anything (though this is much easier to detect :))

[ThomasWaldmann]

working on that.

well, kind of blocked on that. I tried to call require_root in configurator and reverter classes, but then the tests fail as they are run without root (because when invoked from tests they don't need root).

this brings up the issue that we basically do not know which permissions / which euid the code in these classes need. i somehow got the feeling that checking permissions (and doing a failure exit) before trying might be the wrong / rather inflexible approach and just trying (and failing) might be better / more flexible.

@jdkasten and me discussed a bit on irc about that, trying to extract the essentials:

TW you could run apache non-root on highport and port-forward 443 to it

JDK fairly delicate situation and it will be extremely easy to make a privilege escalation vuln.
Sure the sysadmin can be running Apache on a different port, but they should still be protecting their configuration files. I honestly think it would be better to document everything first...
for instance the first thing that comes to mind is that only authenticators should probably be allowed to run without root or rather all Installers should have to run as a "special user" privileged user
Right now I am kind of using a "walled garden" approach where it only touches 'trusted' input (with proper privilege). I think that the privileged user should be able to be configured...

TW what would happen if we do not check? could it proceed to point x, stumble and rollback?

JDK The input can be extremely sensitive and I would like to reduce the attack surface as much as possible. I wrote up a little bit about it here...
https://github.com/letsencrypt/lets-encrypt-preview/wiki/Documentation#notes-on-security
Apache configurations can be Turing complete... with SSI and Rewrite rules

[kuba]

FYI code in master doesn't require root any more.