cron.allow

[Gary Yu]

Hi all,

some documents said that if /var/adm/cron/cron.alow exists and is empty, only root user can use cron. But I tried on my HPUX11.0 server, with an empty cron.allow file, even root user can't use cron:

# crontab -l
crontab: you are not authorized to use cron. Sorry.

who's right then?

any idea is greatly appreciated.
Gary

[Robert-Jan Goossens · Accepted solution]

Hi,

You are,:>)

Users are permitted to use crontab if their names appear in the file
/usr/lib/cron/cron.allow. If that file does not exist, the file
/usr/lib/cron/cron.deny is checked to determine if the user should be
denied access to crontab. If neither file exists, only root is
allowed to submit a job. If only cron.deny exists and is empty,
global usage is permitted. The allow/deny files consist of one user
name per line.

Kind regards,

Robert-jan.

[Sridhar Bhaskarla]

Hi Gary,

The command is right.

Excerpt from the man page of cron


You can execute crontab if your name appears in the file
/usr/lib/cron/cron.allow. If that file does not exist, you can use
crontab if your name does not appear in the file
/usr/lib/cron/cron.deny. If only cron.deny exists and is empty, all
users can use crontab. If neither file exists, only the root user can
use crontab. The allow/deny files consist of one user name per line.

The above says that if the file exists and is empty no one can use cron.

-Sri

[Oleg Zieaev_1]

You might have root listed in cron.deny file.
To avoid confusion add root to cron.allow file.

We only have cron.allow to control crontabs.
Unless you want to deny specific users you do not need cron.deny file.

Hope this helps,
0leg

[Gary Yu]

Thank you Rober, Sri and Oleg.

it really confused me when I first read that part, because it's Mr. Rehman's , a really great book on HPUX.

thanks,
Gary

[F. X. de Montgolfier]

Hi, as the others said, the cron.allow file should be in /usr/lib/cron. On the other hand, /usr/lib/cron should be a logical link to /var/adm/cron... I never saw a HP-UX 11 system where this would not be the case.

Now, if somebody could explain the following behaviour to me, I would be grateful:
I have a cron.allow file, containing 3 users. As root, I can crontab [-l|e] , but the user itself cannot. Which means that I've got a user with a crontab that can be modified only by root. Which is bad, since the user needs a crontab _and_ needs to be able to modify it...

Any input would be greatly appreciated!

Francois-Xavier

[Andy Cole_1]

Hi there,

Since Gary bring up the topic, need to ask you all something also. Is at.allow the same as cron.allow? Is it the same? Please explain thanks

[Robert-Jan Goossens]

Hi,

man at

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.

Kind regards,

Robert-Jan.

[Elif Gius]

Hi,
You can execute crontab if your name appears in the file /usr/lib/cron/cron.allow.If that file does not exist, you can use crontab if your name does NOT appear in the file /usr/lib/cron/cron.deny.If only cron.deny exists and is empty, all users can use crontab. If neither file exists, only the root user can use crontab.

[Andy Cole_1]

hmm..... But what is the difference between at.allow and cron.allow? Do they perform the same function? If so why is there a need to have at.allow and cron.allow? thanks

[Oleg Zieaev_1]

Hello.

at.allow controls at jobs (one time scheduled jobs). cron.allow control cron jobs (day to day jobs).

The principle is the same.

Hope this helps,
0leg