Phase I: Access Control in a Client/Server -- Hints

Last updated 2/27/99

Here are some helpful hints for phase I of the programming assignment.

Part I.1

• Grant the Necessary Permissions   The client connects to the server by opening a socket on port 6666 of localhost. Thus, in order to run the client and server, you must create a policy file that grants permissions for this socket to both the client and server. In addition, you will need to grant the client permissions to use the AWT (see the standard permission documentation) , as well as to grant the ServerStub the RuntimePermission checked for in the Server.

  More generally, to determine what permissions are needed to execute some piece of code, simply try to execute that code. If the Java 2 runtime system throws a security exception then (i) read the error message, (ii) note the permission that is lacking, and (iii) add the necessary lines to the policy file.

• Take Care Typing Policy Files   Java 2 has poor support for debugging policy files. The system does not give warnings about typos and other common errors that you can (and will) make in building a policy file. It is easy to leave-off a slash, for example, and have created a completely useless policy file. (We speak from experience.)

  Also, remember the meanings of the different policy file codebase specifications, as described in the policy file documentation. For example, codebases refer to directories -- not individual files. It is easy to use the wrong suffix on a codebase specification to create a policy file that is too liberal in the permissions it grants. Practice the Principle of Least Privilege!

  A good strategy would be to separate the server and client directories so that it is more difficult to make a mistake is writing your policy files. Once you have finished developing your solution, make sure the directory structure you devised also conforms to the submission directions.

• Edited 2/27:   Safeguard Only Communication Operations   Invocations of CheckPermission or doPrivilege you add in Part I.1 to ensure that
  1. ClientStub can only be used by Client.
  2. ClientComm can only be used by ClientStub.
  3. ServerStub can only be used by ServerComm.
  4. Server can only be used by ServerStub.
  might be added to the red operations in problem specification and to doCommand() in ServerComm.

• Syntax of doPrivileged   This syntax is "magical" and it's easy to make a mistake. Read the doPrivileged documentation -- especially the section on returning values and accessing local variables.

• Set Your classpath Correctly   Make sure all your directories are in the classpath when you compile and run the client and the server. Use the -classpath argument to javac and the -cp argument to java.

• Added 2/22:   Codebases versus classpaths The relationships between codebases in the Java 2 policy file, the "classpath" used by the Java 2 tools, and the way directories are used to create packages in Java 2 is confusing. Packages appear in directories, but only the root of such a directory is usable in policy file codebases or in classpaths. For example, the class A in package B is named B.A and appears as file B\A.class. Permissions for A should be given to the parent directory of B (!!!). Thus, if the full path is Z:\home\fbs\B\A.class then the directory to use in a codebase of a classpath argument is Z:\home\fbs. Confusing? Make codebase and classpath references point to the parent directory of all package directories.

  Returning to GradeSheet, if the client package directory and the server package directory are both placed in the same directory, then both the client and the server will have the same codebase. But this would not allow a policy file to grant different permissions to the client than it grants to the server --- a problem. To circumvent the problem, a different directory structure should be used.

Part I.2

• Use Standardized Principal Names   To make your programming task easier, it is advisable to employ a convention that links principal's names to the operations that those principals are allowed to perform. We recommend assuming that the following ID's will be entered into the Login dialog box:
  • professor   to denote the principal that we called a professor.
  • ta1, ta2, ...   to denote the teaching assistants. Principal ta1 is a teaching assistant that graded project 1; principal ta2 is a teaching assistant that graded project 2; etc.
  • StudentID   The student whose ID is StudentID.

• Interpret the Security Policy using Common Sense   Some aspects of the security policy in the problem specification are not given explicitly or are ambiguous. Use common sense in resolving ambiguities, consistent with the following guidelines:
  • Everybody may see the number of students and the number of projects.
  • Everybody may see all project names and all studentID's.
  • The professor may see all averages.

• Compromise, but ... When Java 2's stack introspection proves awkward for solving part I.2, don't hesitate to abandon it for a better scheme of your own design. We only ask that the code runs, that our desired security policy is enforced, and that your design choices be justified (in your Design Rationale document).

• Added 2/26:   Separate but equal ...   The current implementation of the Client and Server components (client.jar and server.jar) use the fixed port number 6666 to communicate across the network (don't worry if you don't know what this means). Therefore, only one copy of the client and server can be running on a given machine at any one time. If more than one copy is run at once on the same machine --- even if it is because multiple separate users are each running a single copy --- you will get an error like

  java.net.BindException: Address already in use.

  The obvious consequence of this "feature" is that two people/groups cannot use the same multi-user machine to work on the project at the same time.