• A hole in the Linux kernel that could allow a local user to gain root access has been discovered and patched by a number of vendors. So far, Mandrake, Trustix, TurboLinux, Conectiva, Debian, and Red Hat/Fedora have issued patches.
• Several additional vendors patched the problem with XFree86 we reported last week, including SUSE, Conectiva, and Debian.
• In the "announced vulnerabilities" column, you'll want to be on the lookout for patches to Mailman, fetchmail, and the BSD kernel. These vulnerabilities are so recent that, as of press time, no patches had been announced.

Tips of the Trade

Sometimes, when something needs to happen over and over and over again, it's best to just schedule it as a cron job and forget all about it. But what about when you want to schedule something to happen at some point that's "not now," and it needs to happen only once? Consider at.

Where cron depends on a crontab file to decide when to run scheduled commands, at takes input from the command line. Output from an at-scheduled command is mailed to the user, and notification that the command executed (if it wouldn't ordinarily involve output) can be specified by adding on a -m switch.

at allows very specific time designations. So telling at to "run the shell script /home/joe/bin/verybigjob.sh at 3:38 p.m. three days from now" would look like this:

at 3:38pm + 3 days

at also accepts words like "midnight," "tomorrow," "noon," and even "teatime" (which is 4 p.m. -- we looked it up on the man page).

One common point of confusion: Once you issue the at command with its date qualifier, you'll be dumped into a prompt that looks like at>. At that point, you must enter the command (or commands) you want to run, followed by pressing the control and d keys to exit the command.

If you want to see which jobs are waiting to run, use the atq command; if you want to get rid of a job, use the atrm command. To use atrm, you must know the job number (which is returned when you exit at with ctrl-d), or by looking it up with atq.