You are not required to use any of Legion's security options. We realize that not all systems will benefit from our security and Legion can run with or without security. However, you must decide whether or not to enable Legion security before you use your new system: the command-line tool that starts the security mode (legion_init_security) will not run correctly if you have started to work in your system (i.e., if you have created new objects, changed context space, run classes, etc.).
If you are running a multi-architecture system, you will need to register other implementations for each additional architecture (an implementation for your current architecture is automatically created when the system is first initialized). Use the legion_create_implementation command.
If you choose to enable the security features (see "Choose your security setting,") you must run legion_init_security immediately after you have started a new system and you must log in as admin. If you do not enable security, Legion will run normally but none of your processes will be protected.
While all users can "read" (i.e., look at and move to) all of the new context space, non-admin users can "write" (i.e., create new context objects) only in the /home, /etc, /tmp, /mpi, and /pvm contexts. Only admin can "write" in the all parts of context space (Figure 6). Log out is achieved by exiting the shell.
The legion_change_permissions command can be used to alter "read," "write," and "execute" object permissions so that other users can use those objects (see page 11 in the Basic User Manual).
You add users to your system by creating new user ids. A user id is an entry in context space that represents an AuthenticationObject. It is also used to signify ownership of all objects that a logged in user creates.
The legion_create_user command creates new user ids. This command is actually a simple wrapper around the legion_create_user_object command (see page 60 in the Reference Manual). The latter command gives more control in creating AuthenticationObjects, so that you can choose a particular host or vault, or -- if you have another class that can create AuthenticationObjects -- specify the new object's class. We suggest that you put all new users in the /users context.
Please allow about five minutes for the new user to propagate in your system after creating a user id. If the user tries to log in too early, he or she will get security errors when trying to create objects.
On a successful login, a credentials file (a user read-only file) is created in the local /tmp directory (see page 62 in the Reference manual). If security is turned on, the new user should move to his/her home context with the legion_set_context command after logging in.1 For example, nemo would move to /home/nemo:
Once the implicit parameters for a user have been set, you must log out and log in again for them to take affect. Alternatively, legion_set_implicit_params can be used to change the implicit parameters of the current session (if you do not specify a file name the command sets the implicit parameters of the current environment). If you do this, make sure that the implicit parameters contains a certificate definition for your AuthenticationObject, or you will have to log out and log in again in order to execute any further commands as an authenticated user. This documentation does not yet include an example of defining a certificate.
To show the current implicit parameters or the parameters for a particular user, use legion_get_implicit_params. Use legion_set_acl to change the access policy of an existing object: this is not the same as changing implicit parameters, which (in the case of access control) will only affect the creation of new objects. The legion_set_acl tool can have the same input file as legion_set_implicit_params but it only uses the access control information.
If you have created a system with secure files, try creating a file as a logged-in user (the executable testBasicFiles will create a sample one for you). You can experiment with permissions and access control.
Run legion_get_interface to get the names of methods available on an object. The method names follow the output line titled Object Interface. Some of the methods are Legion object-mandatory functions, while others (usually listed at the end) are particular to objects of that class. You can cut and paste lines from the output into an implicit parameters file -- put the names in double quotation marks in the Method definitions. Be sure to make your cut be from the real start and end of the line output by legion_get_interface, since some method names have leading or trailing tabs and spaces. Directing the output of legion_get_interface into a file then editing the file may be helpful.
If a user's AuthenticationObject is deleted there is no way to regenerate an equivalent AuthenticationObject; the user must be re-created from scratch. The reason is that the private key of the original AuthenticationObject cannot be recovered, so the same LOID cannot be used for the object.
1. After you log in, you are in the root (/) context rather than in your home context. back