This topic has not yet been written. The content below is from the topic description.
More precisely, a privileged block consists of an java.security.PrivilegedAction or java.security.PrivilegedExceptionAction object passed to a java.security.AccessController.doPrivileged() call. As of version 2.4, Remoting wraps all security sensitive method calls appropriately. For example, the call java.net.ServerSocket.accept() has been replaced by org.jboss.remoting.utility.SecurityUtility.accept(): static public Socket accept(final ServerSocket ss) throws IOException { if (skipAccessControl) { return ss.accept(); } try { return (Socket)AccessController.doPrivileged( new PrivilegedExceptionAction() { public Object run() throws Exception { return ss.accept(); } }); } catch (PrivilegedActionException e) { throw (IOException) e.getCause(); } } Note that the AccessController.doPrivileged() call, with its creation of a PrivilegedExceptionAction object, is made only if the static variable SecurityUtility.skipAccessControl is set to false, which is the case if no SecurityManager is installed, or the system property org.jboss.remoting.Remoting.SKIP_ACCESS_CONTROL is set to "false". The Remoting code needs quite a few permissions since it interacts extensively with the network, file system, etc., and there are a couple of strategies for granting these permissions. The standard java.lang.SecurityManager can read permission information from an XML file, as described in http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html, and one straightforward strategy is to treat Remoting as highly trusted code and to give it all possible permissions in a file that looks like grant codeBase "file:${remoting.dir}/jboss-remoting.jar" { permission java.security.AllPermission; }; This file grants all permissions to any class loaded from jboss-remoting.jar. Alternatively, a more precisely tailored set of permissions can be crafted to give Remoting, or some subset of its facilities, sufficient permissions to function. The Remoting distribution contains a sample permission set in etc/remoting.security.policy.core. It may be necessary or desirable to modify the file, according to which Remoting components are used, where certain files are located, etc: It may be necessary to change the java.io.FilePermission permissions, according to the configuration of certain files. If Remoting is configured to operate with one or more MBeans in place of POJOs, it might be necessary to grant additional MBeanPermissions. Some facilities always use MBeans. The MBean permissions given in remoting.security.policy.core may be restricted to particular ObjectNames. Some permission may be eliminated, according to which Remoting facilities are used. Other than changes made according to items 1 and 2, it should not be necessary to grant any additional permissions. The etc directory also contains the policy files remoting.security.policy.tests, remoting.security.policy.tests.marshal, and remoting.security.policy.tests.minimal, which are used by the Remoting functional test suite. These files give examples of modifying the permissions given in remoting.security.policy.core. Note. As of release 2.5.3, state changing methods of org.jboss.remoting.InvokerRegistry require permission java.lang.RuntimePermission("invokerRegistryUpdate"). These methods are createClientInvoker() createServerInvoker() destroyClientInvoker() destroyServerInvoker() isSSLSupported() registerInvokerFactories() unregisterInvokerFactories() unregisterLocator() updateServerInvokerLocator() Sample policy file etc/remoting.security.policy.core has been modified accordingly.