I would like information on the entries and file naming convention of at jobs. Looking at the /var/spool/cron/atjobs entries I see a number of files with alphanumeric names and a .SEQ file with one entry, a number corresponding to lowest job number. So here's what I have and what I'd like to do.

I want to automate the creation of at jobs based on data from a mysql table containing the time the job is to be run and some other relevant information. These jobs are run at various times of the day sometimes as many as six or seven times. I'm thinking of using php to read the table and create the jobs as well as update the .SEQ file. I don't think that would be difficult; I have enough examples for the actual file contents. I'm more concerned about the file names.

I would welcome any comments, caveats, critiques, whatever, on this project.

Seems a bit pointless to re-invent a good part of that particular wheel. If you've got the DB, and you're already familiar with building it, populating it, and reading from it, why not just use a system call and use the built-in Linux at command to schedule a job?? Why go through all the trouble of updating a .seq file, etc. Let the built-in Linux utility handle it.

As far as PHP...I'd not use it for command-line stuff personally, but it's certainly an option. I'd probably write it in Perl, but that is just personal preference.

That looks like the better approach. Can you flesh it out a bit more though? Like what do you mean by a system call? Something like php's exec or system? As to my choice of php it's because I'm already using it to manipulate the database via my browser and it would be a relatively simple thing to add one more function, i.e. create the at job.

Well, if you know PHP and you know the "exec" and "system" functions, what else is there to 'flesh out'?? That's it....use those functions to call the at command. Read the man page on the at command to find the syntax to schedule/remove/query a job. Use it as you see fit.
Ok...so add the system call.

Some notes on how I got this thing to finally work using the system call:

The original command was:

$lastline = system("at 23:58 15.11.2012 -f atfile", $retval);

That failed because the php script was running as www-data and this user lacked permission to run the at command as apache helpfully informed me. So I tried prepending 'sudo' and the command now looked like:

$lastline = system("sudo at 23:58 15.11.2012 -f atfile", $retval);

Of course that failed because of the lack of a password. That meant modifying /etc/sudoers with the instructions. At first I tried to make www-data a member of the sudo group who are allowed to issue any command but that didn't work. Apache kept returning the message "sudo: no tty present and no askpass program specified". What did work was adding the following commands in /etc/sudoers:

User_Alias APACHE = www-data
Cmnd_Alias SCHEDULING = /usr/bin/at
APACHE ALL=(ALL) NOPASSWD:SCHEDULING

Now apache is happy, I can schedule from php, and I'm happy. I don't think I've created a security hole because www-data is only allowed to use the at command, nothing else, and that command can't be used to compromise security. If anyone has any thoughts to the contrary or any comments at all please post them.

What is the location, ownership and permissions of "atfile"?
And any parent directories?
Which users are allowed to add or modify data as www-data user?
How do the contents of "atfile" get populated?

Location: virtual server home
Ownership: www-data
Permissions: 0644, read everybody, write owner, no exec
First parent: 0775, read everybody, write owner/group, list everybody
Next parent: 0755, read everybody, write owner, list everybody
Only www-data is allowed to add or modify. Only other member of www-data group is me although that's not relevant to the scheduling job since the process runs as www-data.
The file is created and populated via the php process which runs as www-data.

Do you see any holes?

That is the current situation. A capable developer looks ahead to anticipate changes in use and to avoid problems.


One of the aspects of UNIX architecture is separation of privilege.
You may know it as the "everything that is not explicitly permitted is forbidden" mantra.

Applying that to /etc/sudoers:
Limit the 'at' service to run with specific flags only (I'll get to its use).
Limit the www-data user to run only at (and not any command which is be a security violation of the first order).

Applying the same to the "atfile": the way you use the shell script to drive the at job is like you would use a temporary file: it only concerns the system and it doesn't need to be read by others. If using a permanent directory only user www-data can read and write to isn't possible (in the sense of "can", not "want") then see if 'mktemp' or equivalent can be used to limit exposure. If mktemp can't be used then check if the umask of the controlling process can be temporarily set to 027 before writing the file.
The reason for having the 'at' service run only with "-t" is because you may not even need a temporary file if you can run something like this:

If the process relies on user input, directly or via say a database query, then that could be "interesting" ;-p

Given the above comments I've reworked the code and eliminated the file altogether. I tried the mktemp method but ulimately settled on piping the commands to at. To me this seems as the most secure. In fact I was thinking along those lines but had trouble with it until I saw the example. Then it was just a matter of working the code in order for all the characters to be interpreted as intended. In any case any possible hole due to the processes involving the file are now gone.

The last part is intriguing because the command fed to at is generated by a mysql query. No user input is involved, at least none other than me. I'd be curious to know why you find that "interesting".

Thanks for your input, it's been most helpful.