Issue 326: enable a SecurityManager in gerrit daemon
Status:  Accepted
Owner: ----
Reported by sop+code@google.com, Nov 11, 2009
When we are running our own daemon process we should install a proper
Java SecurityManager to limit what we can do before we start processing
data received over the network.

At a minimum we should try to do things like:

* Permit read under $site_path/static
* Permit read/write under gerrit.basePath
* Permit read/write under cache.directory

* Permit connecting to sendemail.smtpServer, smtpServerPort
* Permit connecting to ldap.server
* Permit connecting to database.url

* OpenID poses a problem, what provider addresses are we allowed
  to connect to in order to perform OpenID discovery?

* Restrict thread creation to our thread pool code

* Disallow pretty much everything else

The SecurityManager is reasonably efficient, and for our use within
Gerrit will only trigger when we have to read or write new content
within a local Git repository, need to expand a resource pool, or
lookup a user's information from LDAP due to cache expiration.  The
performance difference should be negligible.

Most administrators running a JVM process don't bother to setup the
SecurityManager and related policy files because its a huge pain in
the neck to get the access controls per JAR right.  We mostly know
what is needed where within Gerrit and could just do this out of the
box for the administrator.

The JVM sandbox is already pretty good, but locking things down with
the SecurityManager would help to add an additional layer of security
to protect the host system in case of bugs in the application code.

We may also need it to implement a reasonable scripting language for
site extensions.  Most scripting libraries for Java hide dangerous
calls like System.exit from user scripts by relying upon the security
manager to deny access to the user's code resource.