cron getting zero/blank

[skt_skt]

HP-UX B.11.00

we have been observing a particular user's cron job is getting zeroed out randomly.(under /var/spool/cron/crontabs).

i know of only crontab getting zero while editing if the /var FS get filled at the same time.Any one observed similar issue?

[OldSchool]

well...the owner of the crontab can certainly clobber it....

I'd start by asking the "owner" what, if any, changes they were attempting to make.

I take it you mean the file is still there, but empty, as opposed to deleted.

accidents when doing "crontab -e" would cause this. I encourage doing:

crontab -l >
vi
crontab

instead of directly editting it, btw.

[skt_skt]

is it possible to have any kind of auditing seton the system which can be used to track any operation on a particular file? Any idess?

[OldSchool]

First, check ownership / permissions on the directories:

drwxr-xr-x 26 bin bin 3072 Jul 25 2007 /var
dr-xr-xr-x 16 bin bin 1024 Aug 24 2005 /var/spool
dr-xr-xr-x 5 bin bin 1024 Aug 21 14:05 /var/spool/cron
dr-xr-xr-x 2 bin bin 96 Aug 21 14:07 /var/spool/cron/crontabs


and the actual crontabs:
-r-------- 1 root sys 73 Aug 21 14:07 l00s7m
-r-------- 1 root sys 314 Aug 14 14:13 root

It sounds like somebody tried to do "crontab -e" and /tmp was full. if they exited with a "ZZ" or "wq" it would have saved an empty file.

Tripwire may be of some use...it'll tell you the file changed, but not who or how (and aftrer the fact of course)
http://en.wikipedia.org/wiki/Tripwire_(software)

Event auditing might get it, but I believe that is system-wide, not file specific. You might examine the .sh_history file for the user in question, if available. If you've many crontab users, and only one is having issues, then it is almost certainly user error.

[James R. Ferguson]

Hi Santhosh:

In additino to Court's advice for handling 'crontabs' [which I follow too], you might examine the '.sh_history' of the affected user for clues.

You might also look at 'root's '.sh_history' since a properly configured '/var/spool/cron/crontabs' directory holds files owned by *root* and will not allow truncation nor overwriting the files therein by users other than root.

Regards!

...JRF...

[OldSchool]

you might also inspect the jobs run out of root's crontab. Perhaps one of them is accidentally clearing the file.

If the permissions are set properly, root should be the only one who can write/overwrite the user's crontab (except when the user does the "crontab -e" thing noted above)

[OldSchool]

hmmm...james beat me to it...but only by 45 seconds

[James R. Ferguson]

Hi (again):


> OldSchool: hmmm...james beat me to it...but only by 45 seconds

Yeah, I saw that too. Seems like great minds run in the same circle [or, "rut" if you prefer] :-}}

{ too: I said "Court" but meant "OldSchool" }

Regards!

...JRF...

[skt_skt]

yes /var was oned by the cron user who was effected. Just changed. will oberve it.

[skt_skt]

"When first initialized, Open Source Tripwire scans the file system as directed by the administrator and stores information on each file scanned in a database. At a later date the same files are scanned and the results compared against the stored values in the database"

sounds like it reports the difference . will it help to tell what casued the change?

[OldSchool]

from previous post "Tripwire may ..... but not who or how (and after the fact of course)

[Bill Hassell · Accepted solution]

> /var was oned by the cron user who was effected.

That is very bad. The top level directories and mountpoints must never be owned by any user except root. Is the root password secure? That is, do inexperienced or untrained people know the root password?

Another way to zero crontab is to run it without any parameters. An inexperienced user might type: crontab, then the user types ctrl-d to get a system prompt. Now crontab has been blown away by the user. Look at the user's shell history file. Any crontab commands with no option?