If your system administrator has enabled Legion's security features, you must have a user id and log in to Legion before you can start working. Ask your system administrator to create one for you if necessary.
Your system's log in procedure may differ from what is described here, so check with your system administrator for specific instructions. The default system requires all users to have user ids and passwords. This lets Legion keep track of your objects and user privileges. It also prevents malicious users from interfering with your objects or gaining illicit access to your system.
When you log in to a Legion system you are identified by an AuthenticationObject , a special object that contains your password, initial implicit parameters (the Legion equivalent of a Unix "environment"), and other information. AuthenticationObjects are created when you create a user id. A set of Legion commands can be used to retrieve or change this information (see section 2.8 in the Legion Reference Manual for these commands). When an authenticated user runs a Legion process a certificate confirming his or her identify is passed along to verify that this person has permission to run the process. This certificate is created and signed by your AuthenticationObject, so you will have to get a new user id if your AuthenticationObject is destroyed.
Your current working context is automatically set to your home context (/home/<user id>). Use legion_cd to move to another part of context space (see section 5.1.4).
The legion_login command verifies your identity and your security privileges and puts a credentials file in your local /tmp directory. This file is a user read-only file. It is used by command-line utilities to verify your identity. You get a separate credentials file in each shell in which you run legion_login. You own objects you create while logged in. No one else (except the system administrator) can use them unless you specifically give them permission (see "About object permissions"). Any processes that you start after logging in will be accompanied by a copy of your AuthenticationObject's certificate.
If your system administrator has enabled Legion security, the objects that you create while logged in cannot be used by any other users. If you wish to share your objects you need to give other users any necessary read, write, and execute permissions.2 You can use legion_change_permissions to change an object's permissions. The syntax is:
See page 64 in the Reference Manual for more information.
If your site requires you to authenticate via Kerberos in order to log on or otherwise interact with any of the machines at the site (irrespective of Legion), you need to incorporate your Kerberos credentials into the Legion environment. If Legion needs to create a process or a file on your behalf on a remote machine, your Kerberos credentials must be available to authenticate you to the remote machine. To do this you will need to create a Legion proxy object that holds a copy of your Kerberos credentials. Legion can then automatically contact this proxy object whenever it needs your Kerberos credentials for a remote machine.
Kerberos support in Legion is not currently fully documented; a small collection of sites that use Kerberos are working with the Legion developers to define and improve Kerberos support in Legion. In the near future, we will include detailed instructions regarding the creation and use of the Kerberos proxy objects. If you require Kerberos support in Legion, contact us at <firstname.lastname@example.org>.
The second option lets you set the security mode for the Legion message layer. There are three settings: private, protected, and off. We strongly recommend that you read the discussion of the message layer and these security settings before using this option (page 30 in the System Administrator Manual). Any changes you make will be applied to all messages passed by your objects.
Please see the man pages or Reference Manual for information on these commands. Please see page 32 for more information about SKCC classes and backup vaults.