2.8 Security

legion_add_acl 
     [[-c] <object context path> | -l <object LOID>] {-s | <filename>}
     [-debug] [-help]

Adds an access control list to the object named in <object LOID> or <object context path> or, if no object is named, the current environment. This command resembles legion_set_acl, but it merges in a new access control list. For example, if the current access control set contains access control lists for methods A and B of class XYZ's instances, adding new access control lists for class XYZ's methods B and C will not change A, replace B, and add C.

The following options are supported:

-s

Read from stdin.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_add_implicit_params 
     [-l <AuthenticationObject LOID> |
        -c <AuthenticationObject context path>]
     {-s | <filename>}
     [-debug] [-help]

Add an implicit parameter to the AuthenticationObject named in <AuthenticationObject LOID> or <AuthenticationObject context path> or, if no AuthenticationObject is named, the current environment. The arguments take the same input format as legion_set_implicit_params. New parameters merge into the existing implicit parameter set (i.e., new parameters override old ones of the same name). There is no way to remove or unset selected implicit parameters in the AuthenticationObject (please see legion_modify_parameters on page 69 for information on changing your current session's implicit parameters).

The following option is supported:

-s

Read from stdin.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_change_acl
     {[-c] <object context path> | -l <object LOID>}
     <function pattern> <modifications>

Change an access control list (ACL) for a set of functions on a specified Legion object.

Please note that if you have never altered the specified object's ACL before the object's permissions are by default set for Empty Function. In this setting, only the object's owner, the admin user, and the object's class can call the function. When you change the object's permissions for one or more functions, the set of allowed or denied users is merged with the Empty Function list. That is, if you add user John to the Allowed list for object Foo's getInterface(), the list will now contain four users: you (the owner), admin, Foo's class, and John.

The following parameters are required:

<function pattern>

Lets you specify a Unix-like wildcard argument that indicates which functions should be modified. Can contain any standard wildcard pattern (e.g., *, ?, [], and [^]).

<modifications>

A list of statements that add/remove users or groups from the specified functions for the specified Legion object. It can contain these elements:

+allow | -allow | +deny | -deny
{-l <user group LOID> |
[-c] <user group context path>}

Legion checks the Denied list before it checks Allowed, so if a user or group is on both lists, Legion will consider it denied.

You can list multiple <modifications> in a single run. For example, you can alter SomeFile's ACL to allow SomeUser and SomeGroup to call any functions with "read" in them (such as read_hosts_contexts() or get_ready_time()):

$ legion_change_acl /home/legion/SomeFile "*read*" \
   +allow /users/SomeUser +allow /users/SomeGroup

Note that you need full context paths for objects in the <modifications> parameter.

The next example changes SomeContext's ACL. It denies SomeUser and allows SomeGroup the right to call any function with "multiLookup" in it.

$ legion_change_acl /home/legion/SomeContext \
   "*multiLookup*" +deny /users/SomeUser \
   +allow /users/SomeGroup
legion_change_owner 
     [-v] [-r] 
     {[-c] <object context name> | -l <object LOID>}
     {-l <target owner LOID> | -c <target owner context path>
     [-debug] [-help]

Changes an object's owner. This command currently works only on unclaimed objects: if an object is already owned you would have to be logged in as both the current owner and the target owner in order to run this command.

The following options are supported:

-v

Run this command in verbose mode.

-r

Run this command in recursive mode. If the specified <object LOID> or <object context path> is a class, ownership of all instances, sub-instances, etc. will change. If the specified <object LOID> or <object context path> refers to a context object, change ownership of all context entries, recursively applying the operation to sub-contexts will change. In either case, ownership of the root object referred to by <object LOID> or <object context path> is changed.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_change_permissions 
     [+-rwx] [-v] <group/user context path> 
     <target context path> 
     [-debug] [-help]

Changes an object's read, write, and execute permissions so that you can allow the user or group named in <group/user context path> to use the object named in <target context path>. This tool manipulates an object's access control list (ACL) so that other users can call methods on your objects.

For our purposes, "read" methods are defined as methods that obtain but do not modify an object's state, "write" methods are methods that modify an object's state, and "execute" methods are methods that run an object. For example, giving bob "read" permissions for object foo, below, lets him view but not alter foo's state.

$ legion_change_permissions +r /users/bob foo

This command works on common Legion object types: context, file, class, tty, implementation, host, and vault objects all fall into this category.

The following optional parameters are supported:

-r

Deny read permissions to the target object.

+r

Grant read permissions to the target object.

-w

Deny write permissions to the target object.

+w

Grant write permissions to the target object.

-x

Deny execute permissions to the target object (this option is for class objects only).

+x

Grant execute permissions to the target object (this option is for class objects only).

-v

Run the command in verbose mode. You will see a list of the ACLs that have changed.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_create_user 
     [-a <admin path>] [-z <password>] 
     [-h <new home context>] [-c <AuthenticationClass path>] 
     <user id path> 
     [-debug] [-help]

This command is actually a simple wrapper around the legion_create_user_object command. The full command give more control to the creation of AuthenticationObjects.

The user id is the context name of an AuthenticationObject: the legion_create_object utility creates the object and assigns it the context name given in <user id path>. Please note that this argument is a full path (relative or absolute). Note also that the user id's context has nothing to do with that user's privileges in that context. Once a user is created, the legion_login command is used to log in. The command will prompt for a password for the new user (unless you use the -z option), and will return the new object's LOID.

The following options are supported:

-a <admin path>

Specify the admin object's context path. Default is /users/admin.

-z <password>

Specify the new user id's password. The default setting will prompt for the password after the command has been run. This option is not recommended for casual use, since the password will be visible on the command line.

-h <new home context>

Specify the new user's home context. Default is /home/<user id>.

-c <AuthenticationClass path>

Specify the AuthenticationClass which you wish to instantiate. Default is /class/AuthenticationClass.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_create_user_object
     {[-c] <class context name> | -l <class LOID>}
     [-h <host for new object> | -v <vault for new object>]
     [-f <implicit parameter file>] [-z <password>] <user name>
     [-debug] [-help]

Creates a new object to represent a new Legion user id. The new object can be an instance of the AuthenticationObjectClass or another class that implements AuthenticationObjects.

The following options are supported:

-h <host for new object>

Specify where the new object should be created.

-v <vault for new object>

Specify where the new object's persistent state should be stored.

-f <implicit parameters filename>

This option names a file containing implicit parameters to be stored in the newly created AuthenticationObject (handed out on legion_login). The filename can be "-", in which case the command reads the parameters from the standard input.

Note that these are *not* the implicit parameters that control the behavior of the new AuthenticationObject. Upon login, the user's environment will be set to contain the latter set of implicit parameters, and they will affect the creation of all subsequent objects.

This option is intended to make it easier to administer the system. In particular, admin can create user accounts that include implicit parameters that by default give the admin access rights to all of the users' subsequently created objects.

 
-z <password>

Include the new user id's password in the command line. This option is not recommended for casual use, since the password can potentially be seen by other users while the command is operating.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_get_acl 
     [[-c] <object context path> | -l <object LOID>] 
     [-debug] [-help]

Returns the access control list of the object named in <object LOID> or <object context path>, or, if no object is named, the default access control set associated with the current logged-in Legion session. This command returns 2 as its exit status if the object/session has no access control list.

The following options are supported:

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_get_implicit_params 
     [[-c] <object context path> | -l <object LOID>] 
     [-debug] [-help]

Get the implicit parameters of the object named in <object LOID> or <object context path>, or, if no object is named, the current logged-in Legion session. The former is analogous to looking in a Unix .profile or .cshrc for which environment variables get set at login and the latter is analogous to Unix printenv.

The following options are supported:

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_init_Apps

Initializes the Applications package, which extends the basic Legion package. Please see page 9 in the System Administrator Manual for more information on the Legion packages.

legion_init_Extra

Initializes the Extra package, which adds functionality to the core Legion system. Please see page 9 in the System Administrator Manual for more information on the Legion packages.

legion_init_HPC

Initializes the High Performance Computing package, which lets you run programs in Legion. Please see page 9 in the System Administrator Manual for more information on the Legion packages.

legion_init_security

Creates the initial user (called by default /users/admin) in a new Legion system. This command should be run immediately after legion_initialize when you are starting your system. The script creates a new context called /users, a new user object called admin. The context name admin is placed in the new /users context. You will be asked for a password.

After running legion_init_security you must login as admin in order to use the system. Use the legion_login command, with /users/admin as the <user name> parameter. This command only needs to be run once, when the system is first started. There is only one /users/admin in a system, since it has system administrator-like privileges. You can change the admin's password later with the legion_passwd command, if you wish.


legion_login 
     [<user id path> | -l <user id LOID>] [-p <password>] 
     [-debug] [-help]

Allows user to log in to the Legion system as a user, and sets up implicit parameters and security credentials for the user. Note that the command can be run without any arguments (although it will prompt for a user name if a user LOID or user id is not given). User names are context names for AuthenticationObjects (special objects that contain a user password, initial implicit parameters, and other information), created with the legion_create_user command.

On a successful login, a credentials file (a user read-only file) is created in your local /tmp directory. The user's shell must be able to see this file so that his/her command-line utilities can use it. The file will be removed when the user logs out with legion_logout (below). You get a separate credentials file for each shell in which you run legion_login.

The following options are supported:

-p <password>

Enter the password from the command line. This method is not secure.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_logout
     [-debug] [-help]

This logs out a user out of Legion. This command removes the credentials file that is created by the legion_login utility and has the effect of logging the user out of a secure Legion system.

We strongly recommend that users insert this command into a .logout file or some other script that is run when a user logs out. This ensures that credential files do not remain in the system for unnecessarily long periods.

The following options are supported:

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.


     legion_modify_parameters
     [-debug] [-help] <argument>

Allows a user to modify the implicit parameter set for his or her current session. These parameters can include anything the user wishes to place in them but usually include the user's credentials obtained when he or she logged in to their Authentication object.

The <argument> parameter must contain one of the following:

-l
-p [<param type>] <param name>
-d [<param type>] <param name> [<param value>]
-a <param type> <param name> <param value>

If you use -p, -d, or -a in your <argument>, <param type> must be one of the following values:

STRING_PARM

A string parameter.

FUNCTIONID_PARM

A parameter describing a function identifier.

INT_PARM

An implicit parameter containing an integer value.

LOID_PARM

An implicit parameter containing a valid LOID.

The following options are supported:

-l

List all of the implicit parameters in the user's current Legion session.

-p

Print a specific set of implicit parameters in the user's current Legion session.

-d

Delete a specific implicit parameter (or a set) from the user's current Legion session.

-a

Add a new implicit parameter to the user's current Legion session.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_passwd 
     {<user id context> | -l <user id LOID>} 
     [-debug] [-help]

Changes a user's password: the command will prompt for the new password. You must be logged in as either admin or the user in order to successfully run this command. You must provide the full context path for the user id (e.g., /user/<user id>).

The following options are supported:

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_set_acl 
     {[-c] <object context name> | -l <object LOID>} 
     [-s | <filename>] 
     [-debug] [-help]

Sets the access control list of the Legion object named in <object context path> or <object LOID>. The default will set the access control set for the current environment. The input file should be an implicit parameters file (see $LEGION/src/UserObjects/Security/ SampleImplicitParams for an example). The implicit parameters file will be scanned only for access control information pertaining to the specified object or environment; all other entries in the file will be ignored.

This access control list is inherited by any newly created objects in the current login session (it roughly corresponds to a Unix umask).

The following option is supported:

-s

Read from standard input.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_set_implicit_params 
     [[-c] <object context name> | -l <object LOID>]
     [-s | <filename>] 
     [-debug] [-help]

Set the implicit parameters of a specified AuthenticationObject or, if no object is named, the current environment. Any parameters that were previously set are cleared. These are the parameters that the user inherits when he logs into Legion. They are passed along as different Legion commands are executed and are similar to environment variables that user might set up in a Unix .profile of .cshrc file.

If no AuthenticationObject is specified, the current Legion login session's implicit parameters are modified (the changes will not persist to the next login session). The command reads the implicit parameters from a file (or the standard input). A sample file can be found in $LEGION/src/UserObjects/Security/SampleImplicitParams.

The following option is supported:

-s

Read from standard input.

-debug

Catch and print Legion exceptions.

-help

Print command syntax and exit.

legion_set_message_security
     [-c <AuthenticationObject context path> | 
       -l <AuthenticationObject LOID>]
     {Off | Protected | Private} [-help]

This command updates the message layer security setting of an AuthenticationObject or the current environment by changing the "MessageSecurity" implicit parameter. There are three possible settings: Off, Protected, and Private. The setting determines the object's message encryption level. The default setting is Protected.

The arguments take the same input format as legion_add_implicit_params (page 62). New parameters merge into the existing implicit parameter set (i.e., new parameters override old ones of the same name).

You must include one of the following parameters:

Off

No encryption or digesting of messages

Protected

Message digested for verification and credentials encrypted for authentication

Private

Message and credentials encrypted for authentication and verification

The following option is supported:

-help

Print command syntax and exit

legion_show_acl
     {[-c] <object context path> | -l <object LOID>}
     [<function pattern>] [-showLoids]

Display an object's access control list (ACL) in human-readable form. The optional <function pattern> argument allows you to use Unix-like wildcard arguments to control which functions are listed. The output may list one or more users as Unknown. This means that you do not have permission to see that user(s)'s context name.

The following options are supported:

<function pattern>

Lets you use a Unix-like wildcard argument to list specific functions. You can use any of the standard wildcard patterns (*, ?, [], and [^]).

-showLoids

If Legion is unable to display a user's or group's context path, it will print a LOID (instead of unknown).

For example, if you asked to see object /home/spw4s's ACL for all functions containing "MayI" in their names, you would see something like this:

$ legion_show_acl /home/legion "*MayI*"
          Access to Function "_4MayI_6GetACL":
                  Allowed:
                          /users
                          <Unknown>
                          /users/legion
                  Denied:

          Access to Function "_4MayI_6SetACL_23LRef<AccessControlList>":
                  Allowed:
                          <Unknown>
                          /users/legion
                  Denied:

          Access to Function "_4MayI_17LegionCheckAccess_30LRef
          <LegionFunctionIdentifier>23LRef<AccessControlList>
          26LRef<LegionCertificateSet>i":
                  Allowed:
                          Empty
                  Denied:
$

The results list each function's Allowed and Denied list. Notice that the third function's Allowed list is "Empty." This means that it contains an Empty Function set, the default setting for all Legion object functions. The Empty Function set contains the object's owner, the admin user, and the object's class. These three objects are automatically given permission to call all of the object's functions. You can use legion_change_acl to change these lists (page 62).

Directory of Legion 1.8 Manuals
[Home] [General] [Documentation] [Software]
[Testbeds] [Et Cetera] [Map/Search]

Free JavaScripts provided by The JavaScript Source

legion@Virginia.edu
http://legion.virginia.edu/