at problems

[Dieter S. Vener]

Hi,

I just added a user to /usr/lib/cron/at.allow. When this user tries to run at, they get the following error:

Open '/var/spool/cron/atjobs/../_at26904' failed errno=13
can't create a job for you

Help

[Orhan Biyiklioglu]

Did you restart cron servise?

/sbin/init.d/cron stop

/sbin/init.d/cron start

[Matthew_50]

`ls -ld /var/spool/cron/atjobs`, check if the directory owner and group belongs to bin, if not, use chmod -R bin:bin /var/spool/cron/atjobs

[Dieter S. Vener]

I did try restarting cron. The ownership on the atjobs directory is bin:bin 555.

Thanks

[Stephen Keane]

What happens if the user enters

# at -l

[Dieter S. Vener]

%at -l

Returns nothing

[Rodney Hills]

Does the directory "/var/spool/cron/tmp" exist and does it have permissions of rwxrwxrwt ?

Rod Hills

[Dieter S. Vener]

Yes

[Stephen Keane · Accepted solution]

If a user that isn't authorised to use "at" issues the command "at -l" you'd get an error message "you are not authorized to use at. Sorry.". The fact that you don't get such an error message indicates that the user IS allowed to use "at".

Do you have any other users allowed to use "at". Can you try them to see if all (non-root) users are affected, or just this one. If it's just this one, is it in a different group or anything?

[MarkSyder]

Error number 13 means permission denied. Could it be the command the user is trying to run that is generating the error message rather than the at job?

Mark Syder (like the drink but spelt different)

[Muthukumar_5]

Check /usr/lib/cron/at.allow file.

# ls -l /usr/lib/cron/at.allow
-r--r--r-- 1 bin bin

Your user name has to be there.

Example:

add test user.

# su test
$ echo "hi" | at 0815 Sep 24
warning: commands will be executed using /usr/bin/sh
job 1127571300.a at Sat Sep 24 08:15:00 2005
$
$
$ at -l
1127571300.a Sat Sep 24 08:15:00 2005

hth.

[Arunvijai_4]

Hi,

Take a look at the man page of at command, It reads,
Users are permitted to use the at and batch commands if their user names appear in the file /usr/lib/cron/at.allow. If that file does not exist, users can use at and batch if their names do not appear in the file /usr/lib/cron/at.deny. If neither file exists, only superuser is allowed to submit jobs. If only at.deny exists but is empty, all users can use at and batch. The allow/deny files consist of one user name per line.

All users can list and remove their own jobs. Users with appropriate privileges can list and remove jobs other than their own.

-Arun

[Dieter S. Vener]

Hi,

I do understand that at.allow and at.deny files exist and do know how to use them. The user is in at.allow and this is not the only user that does not work. In fact, root is the only user that works. I believe that I am experiencing an internal error from at because setuid permissions are wrong somewhere. I think that the permissions of one or some of the files that at uses is not set correctly. One of my admins used CIS to lock down the system and followed the recommendations to change permissions on a lot of files. I do not recommend that anyone follow all of CIS's recommendations! Some of CIS's recommendations are really bad. Great tool, it makes the system so secure that you can't use it:) (sarcasm)I'm actually surprised that CIS did not recommend that I unplug the network cable and turn off power to the server. I think we have fixed most of the things that were broken by implementing recommendations by CIS. Can anyone give me a list of files that at uses and which ones must have setuid root permissions? Starting over from scratch is not really an option at this point. Thanks for all the help thus far.

Thanks

[Pete Randall]

According to the man page, the following files are involved:

-r-xr-xr-x 2 bin bin /usr/bin/sh
-r--r--r-- 1 root sys /var/adm/cron
-r--r--r-- 1 bin bin -r--r--r-- 1 bin bin/var/adm/cron/.proto
-r--r--r-- 1 bin bin /usr/lib/cron/at.allow
-r--r--r-- 1 bin bin /usr/lib/cron/at.deny
-r--r--r-- 1 bin bin /var/adm/cron/queuedefs
dr-xr-xr-x 2 bin bin /var/spool/cron/atjobs


Pete

[Dieter S. Vener]

Ok, I figured it out. The at executable itself must be setuid root. I looked on another system.

[Sheriff Andy]

Have you done a tail on the /var/adm/cron/log file to see what activity is going on?

[Bill Hassell]

There may be a *LOT* of damage still hidden from the 'improvements' to the system files. Luckily, HP-UX haas a very smart software installer called Software Distributor and the problem finder is called swverify. Use it to verify the various OS subsystems and it will tell you what was changed and what it should be (ownership and permissions).