Checking Xi-Batch File and Directory Permissions

How Xi-Batch Uses File Permissions

Xi-Batch holds the live job queue and variable list in shared memory and keeps saved copies of both in its spool directory. The scheduler, btsched, changes directory to the spool directory when it starts, creates the files it needs there, and rewrites the saved copies periodically and at shutdown. It runs as root and hands the files it creates to the batch user.

Key files in the spool directory:

• btsched_jfile.xbjl6 - saved record of the job queue (plain btsched_jfile on a build made without libxml2)
• btsched_vfile.xbvl6 - saved record of the variables (plain btsched_vfile on a build made without libxml2)
• btsched_reps - report file, where btsched and xbnetserv record errors. This is the first file to look at when anything goes wrong
• btufile6 - user permissions, read by every user command
• cifile - the command interpreter definitions
• holfile - the days set as holidays
• btjob.lock, btvar.lock and btxfer.lock - lock files, truncated each time the scheduler starts
• btmm_jobs, btmm_vars and btmm_xfer - present only on a build configured to use memory-mapped files in place of shared memory
• SPnnnnnnnn, SOnnnnnnnn and ERnnnnnnnn - a queued job, its standard output and its standard error

Job submission and the other client requests travel over a Unix domain socket, btsched_req, which lives in a separate sockets directory alongside the spool directory (by default /var/spool/xi/btuds). A permission problem there stops commands reaching the scheduler even when the spool directory itself is correct.

Expected Configuration

Note: The paths used below are the build defaults. Your installation may use others, so start by finding the spool directory as shown under Verification Commands.

A correct installation looks like this:

• The spool directory is owned by the batch user and set to 755. The packages create it that way.
• The files in it are owned by the batch user. That account name is fixed when the product is built and is batch by default; where no such account exists the scheduler owns the files as root instead.
• The scheduler creates btsched_jfile.xbjl6, btsched_vfile.xbvl6, cifile, btufile6, the lock files and the queued job files as 600. holfile is created as 644 and btsched_reps as 640.
• The user commands - btq, btjlist, btjdel, bts, btr and the rest in /usr/local/bin - are installed set-user-id to the batch user, which is how they reach files the person running them cannot open directly. Clearing the set-user-id bit breaks them exactly as changing the file ownership does.

Verification Commands

# Find the spool directory. If SPOOLDIR is commented out in the master
# config file, the built-in default /var/spool/xi/batch is in use.
grep SPOOLDIR /etc/xi/batchconfig

# Check the spool directory and the sockets directory
ls -ld /var/spool/xi/batch /var/spool/xi/btuds
ls -la /var/spool/xi/batch/

# Check key files specifically
ls -l /var/spool/xi/batch/btsched_jfile.xbjl6
ls -l /var/spool/xi/batch/btsched_vfile.xbvl6
ls -l /var/spool/xi/batch/btsched_reps
ls -l /var/spool/xi/batch/btufile6
ls -l /var/spool/xi/batch/cifile

# Check the user commands are still set-user-id to the batch user
ls -l /usr/local/bin/btq /usr/local/bin/btjlist /usr/local/bin/btjdel

# Verify your user context
whoami
groups

Setting Correct Permissions

If files need adjustment:

chown batch: /var/spool/xi/batch/*
chmod 600 /var/spool/xi/batch/btsched_jfile.xbjl6
chmod 600 /var/spool/xi/batch/btsched_vfile.xbvl6
chmod 600 /var/spool/xi/batch/btufile6
chmod 600 /var/spool/xi/batch/cifile
chmod 640 /var/spool/xi/batch/btsched_reps
chmod 644 /var/spool/xi/batch/holfile

Write chown batch: rather than naming a group explicitly: the RPM packages place the batch account in the daemon group while the Debian packages give it a group of its own, so the right group differs between installations. The scheduler runs as root and resets the ownership of the files it creates each time it starts, so hand-set ownership matters most for files a user command created and for the spool directory itself.

When Permissions Are Incorrect

You may notice:

• User commands stopping with "Cannot open files - check ownership of files in spool directory", which goes on to name the effective and real user id the command is running under
• Commands like btjlist or btjdel stopping with "Panic! Cannot read job queue", which points at the owner of the shared memory segments differing from the set-user-id of the command
• The scheduler failing to start, reporting that it cannot change directory to the spool directory, or "Could not create job file"
• Job submission failing because the request socket in the sockets directory cannot be opened

These indicate the files need ownership or permission adjustment as shown above.