SECURE_JOB_INFO_LEVEL

Syntax

SECURE_JOB_INFO_LEVEL=0|1|2|3|4

Description

Defines an access control level for all users. Specify a level (0 to 4) to control which jobs users and administrators (except the primary administrator) can see.

For LSF users, there are three types of jobs:

The user’s own jobs.
Jobs that belong to other users in the same user group.
Jobs that do not belong to users in the same user group.

There are two kinds of job information which will be viewed by users:

Summary Information:

Obtained from bjobs with options other than -l, such as -aps, -fwd, -p, -ss, -sum, -W, -WF, -WP, -WL, etc.
Detail Information:

Obtained from bjobs -l, bjobs -UF, bjobs -N, bjdepinfo, bread, and bstatus.

There are two kinds of user rights which will determine what kind of information a user can view for a job:

Basic rights: User can see all summary information.
Detail rights: User can see all detail information.

When a user or admin enters one of the commands to see job information (bjobs, bjdepinfo, bread, or bstatus), the SECURE_JOB_INFO_LEVEL controls whether they see:

Just their own jobs’ information. (level 4)
Their own jobs and summary information from jobs in the same user group. (level 3)
Their own jobs, summary and detail information from jobs in the same user group. (level 2)
Their own jobs, summary and detail information from jobs in the same user group, and summary information from jobs outside their user group. (level 1)
Summary and detail job information for all jobs. (level 0)

Note: If SECURE_JOB_INFO_LEVEL is set to level 1, 2, 3, or 4, check if SECURE_INFODIR_USER_ACCESS is enabled (set to Y). If it is not enabled, access to bjobs functions will be restricted, but access to bhist / bacct will be available.

Note: In a MultiCluster environment, the SECURE_JOB_INFO_LEVEL definition still applies when a user attempts to view job information from a remote cluster through the bjobs -m remotecluster command. The security level configuration of a specified cluster will take effect.

Interaction with bsub -G and bjobs -o

If a user submits a job using bsub -G, the job will be treated as a member of the -G specified user group (or default user group). For example: UserA belongs to user groups UG1 and UG2. UserA submits Job1 using bsub -G:
```
bsub -G UG1
```
UserA submits Job2 without using bsub -G. Job1 will be treated as belonging to UG1 only. Job2 will be treated as belonging to UG1 and UG2. The result is that members of UG1 can view both Job1 and Job2 details if they are given access rights to view jobs in the same user group. Members of UG2 can view only Job2 if they are given access rights to view jobs in the same user group.
If a user has only basic rights, bjobs -o returns only values in the basic fields (others display as "-"): Jobid, stat, user, queue, job_name, proj_name, pids, from_host, exec_host, nexec_host, first_host, submit_time, start_time, time_left, finish_time, %complete, cpu_used, slots, mem, swap, forward_cluster, forward_time, run_time.

Limitations

An administrator may not have permission to see a job, but they can still control a job (for example, kill a job) using the appropriate commands.
When job information security is enabled, pre-LSF 9.1 bjobs and bjdepinfo commands will be rejected no matter who issues them because mbatchd cannot get the command user name. A "No job found" message will be returned.
When job information security is enabled, users may have rights to only view job summary information and no rights to view job detail information. Therefore, a user would see job info when viewing summary info (using bjobs <jobid>), but an error (job <jobid> is not found) will be returned when the user tries to view job detail information (using bjobs -l <jobid>).

Default