Xi-Batch User Privileges and What Each One Allows

Understanding Privileges

Privileges control access to Xi-Batch functions. Each user has a set of privileges determining what they can do.

Privileges vs modes:

Privileges

System-wide capabilities held by the user - may they create jobs at all, may they stop the scheduler, may they administer other users.

Modes

Per-job and per-variable permissions held by the object - may this user read that job, may they write that variable. Modes are described in Understanding Modes on Jobs and Variables.

The two interact in one place only: the three combine privileges below change how a job's or variable's modes are evaluated for the user who holds them.

The Nine Privileges

There are nine privileges. Xi-Batch shows the abbreviation in the privilege column of btulist and on the btuser user list, and the abbreviation is what you type when you set a privilege from the command line.

Default Privileges

Standard user:

Create entry (CR):          Yes
Change default modes (Cdft): Yes
All others:                 No

root and the Xi-Batch account:

All privileges: Yes

These two accounts are forced to hold every privilege each time the user file is written, so an attempt to take a privilege away from either of them is accepted by the editor and then discarded. Their power comes from their entry in the user file, not from their uid - a restored or hand-edited user file that omits them leaves nobody able to administer the system.

How a User Gets Their Privileges

The user file holds one default record and an entry only for those users who differ from it. A user with no entry of their own is read at the defaults. When you change the defaults, every user who has never been given settings of their own changes with them - the change is not confined to users added later.

A user whose settings are edited back to exactly the default values loses their individual entry again.

Viewing Privileges

Your own account:

btuser -d

Prints your priorities, load levels, privileges and default job and variable modes, and exits. This needs no privilege. btuser with no options does the same - it does not open the user list.

All users (requires RA):

# One line per user, plus a DEFAULT line
btulist -H

# Just the user name and privileges
btulist -H -F "%u %p"

# Named users only
btulist -H -F "%u %p" jsmith mjones

A user holding every privilege shows as ALL in the privilege column rather than a list of nine abbreviations. The DEFAULT line shows the settings inherited by any user without an entry of their own; suppress it with -s, or show only it with -S.

Browsing interactively (requires RA):

btuser -v

Move with j and k, then press p to view a user's privileges or P to view the defaults.

Granting and Revoking Privileges

Requires: write admin file (WA) privilege

Command line:

# Grant special create to two users
btuchange -u -p SPC jsmith mjones

# Revoke it - a leading minus removes
btuchange -u -p -SPC jsmith

# Several at once, comma-separated
btuchange -u -p RA,-ST,-SPC jsmith

# Grant everything
btuchange -u -p ALL jsmith

-u takes no value: it means "act on users", and the users are named after the options. With no names, the change is applied to every user, which is rarely what is intended. The privilege names are the abbreviations from the table above and are matched without regard to case.

Interactively:

1. Run btuser -i
2. Move to the user with j and k
3. Press p for that user's privileges, or P for the defaults
4. Move down the list with j and k, and for each privilege:
   • Y, y, T or t to set
   • N, n, F or f to unset
   • ~ or ! to invert
   • D to return that privilege to the default value
5. Press q or Q to leave the privilege list

Privileges That Imply Others

Setting or clearing one privilege can move another, in both the interactive editor and btuchange -p:

• Setting WA sets every other privilege.
• Setting SPC also sets CR - special create is meaningless without create.
• Clearing CR also clears SPC.
• Clearing RA also clears WA.
• Clearing Cdft also clears WA.

Special Create in Detail

Allows:

• Submitting a job with a load level other than its command interpreter's
• Changing the load level of an existing job
• Adding, changing and deleting command interpreters with btcichange, and editing them from the btq interpreter screen

Without it:

A job takes the load level of the command interpreter it uses. Supplying a different one is refused at submission, and the load level field in the interactive screens is read-only.

Grant it carefully. A user with special create can give a job any load level up to their own maximum, which is how load levels are made to mean something.

The Combine Privileges in Detail

Every job and variable carries three permission sets - owner, group and other. Normally a user is tested against the owner set if they own the object, against the group set if their primary group matches the object's group, and always against the other set.

The three combine privileges merge two of those sets before the test is made, for the user who holds the privilege. They belong to the user doing the accessing, not to the object:

UG (user and group):

Job owned by jsmith, group staff
  Owner set:  Read, Write, Delete
  Group set:  Read

mjones is in group staff, and holds UG
  Effective:  Read, Write, Delete

This is the useful one, and the one to be careful with: it gives every member of a group the owner's rights over every job and variable belonging to that group, including delete.

UO (user and other):

Merges the owner and other sets, which extends the owner's rights to everyone the holder can already see.

GO (group and other):

Merges the group and other sets, removing any distinction between them for this user.

Common Configurations

Standard user

CR Cdft

Submit jobs, create variables, adjust their own default modes. This is what a user gets with no entry in the user file at all.

Team lead managing a group's jobs

CR Cdft UG

Full access to everything owned by their primary group, without any administrative rights over other users.

Developer needing load levels

CR Cdft SPC

Can set job load levels explicitly and maintain the command interpreter list.

Read-only administrator

CR Cdft RA

Can run btulist and browse users with btuser -v, and change nothing. Useful for audit and monitoring.

Administrator

ALL

Setting WA sets the rest.

Changing the Defaults

Requires: write admin file (WA) privilege

# Set the default privileges for users without an entry of their own
btuchange -D -p CR,Cdft

# Set them and copy them over every existing user
btuchange -D -A -p CR,Cdft

-D edits the default record and may not be combined with user names. -A additionally overwrites every user's privileges, priorities, load levels and default modes with the defaults - it is not confined to the setting you just changed. Interactively the same two operations are P (edit the defaults) and A (copy defaults to all users) on the btuser -i screen; a copies the defaults to the user under the cursor only.

Your own privileges are not overwritten by a copy-to-all.

Security Notes

Limit write admin file. WA carries every other privilege, including the right to take over any job or variable in one step.

Treat UG as a grant of ownership. It gives group members the owner's rights, delete included, over the group's jobs and variables.

Grant special create only where load levels matter. Without it users cannot escape their interpreter's load level.

Keep stop scheduler narrow. It also controls connecting and disconnecting remote hosts.

Check the defaults before the exceptions. Most users have no entry of their own, so the default record is what they are running on.

Verify with a test account. Log in as an ordinary user and run btuser -d to see the privileges as that user actually holds them.