test

Trusted Solaris Administrator's Procedures

Administering cron, at, and batch Jobs

In the Trusted Solaris environment, the Job Scheduler tool in the Solaris Management Console manages jobs. This section describes the difference in managing cron(1M) and its associated commands in the Trusted Solaris environment. See the System Administration Guide, Volume 2 for basic cron information. For Trusted Solaris modifications see also the man pages for at(1), atq(1), atrm(1), cron(1M), and crontab(1).

In the default policy.conf(4) file, all users are assigned the Basic Solaris User profile. This profile includes the Edit Owned Jobs authorization. The authorization enables users to manage their own cron or at jobs.

The crontab file is generated by a user or role account using the crontab(1) command. The atjob file is generated by a user or role account using the at(1) or batch command. In the Trusted Solaris environment, the crontab, at, and batch commands must be in one of the account's rights profiles.

In the Trusted Solaris environment, the crontabs and atjobs spool directories are MLDs that hold job files at different labels. With MLDs as spool directories, one user can have multiple crontab files at different labels within the crontabs directory, and, similarly, one user can have multiple atjob files at different labels within the atjobs directory.

Running a Job with a Profile Shell

Caution - Caution -

If a job requires that a profile shell execute the job, the Security Administrator role must ensure that all of the job's commands are also in a rights profile assigned to the invoking user.

cron jobs can be executed using a profile shell. Profile shells are documented on the pfexec(1) man page. A profile shell can execute a cron job if:

For at jobs there is a third case in which the profile shell is used. A user can use the at program with the -c (for csh), -k (for ksh), -s (for sh), option along with the -P (for profile shell) option to specify the shell which should run the job. Therefore, at jobs are executed in the profile shell if:

Running Privileged Commands in Scheduled Jobs

If a command in an at or cron job needs to run with privileges, either forced or inheritable privileges may be made available. Enabling a command to run with forced privileges, so that the privileges apply no matter who executes the command, is insecure practice. Therefore, the Security Administrator role typically does the following to make the privileges available by inheritance:

  1. Specify the command and any privileges it needs in one of the invoking user's profiles using the Rights tool in the SMC.

  2. Specify that the job is executed with a profile shell, as described in "Running a Job with a Profile Shell".

    For more information, see "Assigning Inheritable Privileges to a Command or Action".

    For a cron job example, see "To Write a Profile Shell Script".

How the UNIX Domain Socket is Used for Communications

The communication mechanism between crontab(1), at(1), atrm(1), and cron(1M) in the Trusted Solaris environment is a UNIX domain socket. See the man page for libt6(3NSL).

The cron(1M) command is modified to create and bind the UNIX domain socket at ADMIN_LOW to /etc/cron.d/CRON. The /etc/cron.d/CRON file is also used as a lock file to prevent more than one execution of the clock daemon.

After it creates the UNIX domain socket, the cron command is changed to run at ADMIN_HIGH. The /var/cron/log file is created by the clock daemon at ADMIN_HIGH. The clock daemon logs its internal messages in this log file.

An ancillary file is created in the crontabs MLD for each crontab file and in the atjobs MLD for each atjob file. Modification of a crontab or an atjob file also changes the ancillary file data. The ancillary file is named username.ad for a crontab file, and jobname.ad for an atjob file. The ancillary file contains information used by cron to set up a job.

Trusted Solaris software is delivered with the following /var/spool/cron/crontabs files:

Permitting Users to Access Others' Jobs

The default Trusted Solaris security policy does not permit users to access jobs owned by other users. To enable certain users to access jobs belonging to other users, the Security Administrator role can edit system files, or assign to the user a network-wide authorization through the Scheduled Jobs tool in the Solaris Management Console.

Conditions for Access to Other's Jobs

An account invoking the at, atq, atrm, or crontab commands can look at, edit, or remove jobs belonging to another user only when the following conditions are met.

For the at, atq, or atrm commands, the following conditions must apply:

  1. The specified username or the username of the specified job's owner is one of the special system account names listed in the at.admin file and condition 3 is true, or

  2. The username of the specified at job's owner is the name of a role account and condition 3 is true.

  3. The account has the Edit Owned Jobs authorization in a rights profile.

  4. If neither condition 1 nor condition 2 is true, the invoking account must have the Manage All Jobs authorization in a rights profile.

For the crontab command, the following conditions must apply:

  1. The specified username is one of the special system account names listed in the cron.admin file and condition 3 is true, or

  2. The specified username is one of the role account names and condition 3 is true.

  3. The invoking account has the Edit Owned Jobs authorization.

  4. If neither of 1 or 2 is true, the invoking account must have the Manage All Jobs authorization in a rights profile.