Installing an Instance of SecurityManager

SecurityManager is queried to see whether the operation succeeds. Thus, for example, attempting to read data from a file involves asking the security manager if the program is allowed to read data from the file. To see this in action, lets look at the constructor from the FileInputStream class: public FileInputStreamString name throws FileNotFoundException { SecurityManager security = System.getSecurityManager ; if security = null { security.checkReadname; } fd = new FileDescriptor ; openname; } The first thing this constructor does is obtain the installed instance of SecurityManager and ask it whether the file can be read. If the application doesnt have permission to read the file, an exception is thrown. Similarly, the constructor for Socket begins with the following code snippet, which calls the installed security manager and checks to see if a connection is allowed: private SocketInetAddress address, int port, InetAddress localAddr, int localPort, boolean stream throws IOException { this ; if port 0 || port 0xFFFF { throw new IllegalArgumentExceptionport out range:+port; } if localPort 0 || localPort 0xFFFF { throw new IllegalArgumentExceptionport out range:+localPort; } SecurityManager security = System.getSecurityManager ; if security = null { security.checkConnectaddress.getHostAddress , port; } .... } Its important to note, however, that if there is no installed instance of SecurityManager , neither of these checks occurs. This is a general pattern: unless a security manager is installed, no permissions are checked, and applications have permission to perform any operation. This is necessary for backwards compatibility retrofitting the Java 2 security model onto older applications is a time-consuming and difficult task but makes the overall framework slightly more error prone.

20.3.1 Installing an Instance of SecurityManager

Only one instance of SecurityManager can be installed in a JVM, and it cannot be replaced. The simplest way to install a security manager is to set the java.security.manager system property when launching the JVM, as in the following example: java -Djava.security.manager application This will create an instance of the SecurityManager class and install it when the JVM is launched, before any application-specific code starts to run. Using the system property to install a security manager is often very convenient. For example, when I download Java applications from the Internet, I always install a security manager from the command line. Doing this helps limit the damage a malicious or poorly written program can cause. You can also use the java.security.manager parameter to specify a particular security manager, as in the following example: java -Djava.security.manager =java.rmi.RMISecurityManager application Ordinarily, however, when you write an RMI application, you include a security manager by calling System.setSecurityManager , as in the following line of code: System.setSecurityManagernew RMISecurityManager The reason for this is simple: RMIs dynamic classloading features wont work unless your application has an instance of SecurityManager installed. If you use dynamic classloading, relying on the user, or a batch file, to install an instance of SecurityManager is a bad idea. RMI provides a simple security manager, named RMISecurityManager , in the java.rmi package. In Java 2, RMISecurityManager simply subclasses the standard security manager without adding any functionality at all. Most RMI applications use RMISecurityManager or a custom subclass of it for two very simple reasons. First, using RMISecurityManager instead of the standard security manager effectively documents why the security manager was installed and thus makes it less likely that someone will modify the code to remove the security manager without thinking. Second, it automatically allows code to evolve as RMIs security model gets more elaborate; if you use an instance of RMISecurityManager , then when the RMISecurityManager s implementation becomes more sophisticated, your code will automatically evolve.

20.3.2 How a Security Manager Works