Crontab file permissions

[Brian Ritzinger]

Running HP-UX 10.20 cron file permissions change to be owned by root after using "crontab -e" as another user. We have to chown the crontab back to the correct user everytime we edit the file in this way. Our info sec group mandates crontabs must be owned by the user not root. Any thoughts?

Thanks,
B

[Michael Tully]

Have you tried editing the crontab file as the user themselves?

# su - otheruser
$ crontab -e
make changes, save file
$ logout

Or an even better practise, as the other user, use:
$ crontab -l >myfile
$ vi myfile
make change and save
$ crontab myfile

The files must be owned by the relevant user.
Also suggest you check patches in case there is one.

[Brian Ritzinger]

Yes all changes to cron are done after su'ing to that user. It does not matter if I "crontab -e" or dump it to a file first and then "crontab newcron". The ownership changes to root. I was hoping someone might have seen this and knows if a patch exists.

[Brian Ritzinger]

I believe I found the patch PHCO_19985. Now getting it on my system is another problem.

[Michael Tully]

That patch does not require any type of downtime. Also it has been superceded. See patches PHCO_22768 and PHCO_27422

[Brian Ritzinger]

I looked at the other two, neither describe fixes to permissions. I did however find 19985 on a depot at my work. I just installed it. It did not fix my ownership problem but the crontab files are now modified/created as 400. They were 444 :)

[Steven E. Protter]

It is possible, and probable based on my read of this thread that the permissions on the crontab files manually got out of whack.

I'm no expert on 10.20, though I used it as a part time admin for a while.

Got some bad news for your security group.

Proper permissions on crontab files on 11.11

-r-------- 1 root dba 3571 Oct 8 11:16 oracle
-r-------- 1 root sys 7633 Oct 2 11:10 root
-r-------- 1 root sag 1463 Sep 24 11:09 sag


Note root owns it, but the group is the primary group of the user that should own it.

I did not modify the permissions on this file.

I have found over the years that messing around with permissions on certain files is a recipe for overnight work. It might be fine to change the permissions on those files, and Michael's practices are good, should be followed.

It might be fine to put platinium tip spark plugs in my Truck. It might make me more secure because I can get away from criminals faster. But... It might damage the engine. Bad analogy, but its been a long day.

It might have an unintended nasty effect as well.

Sometimes the default permissions on files are bad. In this case, the permissions are very tight, the crontab -e command lets you access them as the user involved.

With my usual lack of subtley, your security people, do they know Unix? Why are the mandating this change? Does it make sense?

If not in this case these questions may need to be asked in other mandated standards.

SEP

[Brian Ritzinger]

Somewhere, sometime a policy was made that stated users cron files should be owned by that user. There are many security policies, where I work, that I think are plain silly. I just checked a Solaris system and found the same "problem". Which I now think is not a problem. Unfortunately changing the policy is easier said than done.

Thanks for the replies.

[James Lynch]

Brian,

The behavior that you are seeing is normal. For 10.20 and 11.11 the behavior is exactly the same. The files are owned by root with the group ID set to the ID of the user.

A little UNIX history, many releases ago crontab files used to be owned by the user and not root. It sounds like the author of your security policy is still remembering that tidbit of information.

JL