non-root user cannot edit its own (existing) crontab

[F. X. de Montgolfier]

Hello,

I have a HP-UX11.0 system with 3 users set in cron.allow.
As root, I can crontab -e without any problem, and the crontab is executed.
As , though, "crontab -"l" doesn't show anything, "crontab -e" doesn't allow me to edit my crontab and "crontab file" doesn't overwrite the crontab.

The user _must_ be able to change its crontab. Does anybody know what may be the cause of this?
All unnecessary inetd services have been closed due to security requirements. May one of the "superfluous"services be in fact needed? If so, how comes that root can use the crontab?

Regards,

Fran??ois-Xavier

[Rodney Hills]

Could be a permissions/ownership issue. As root, try removing the /usr/spool/cron/crontabs/USER file. Then log on as USER and use "crontab file" to create the crontab entry.

HTH

-- Rod Hills

[Christopher McCray_1]

Hello,

Was the crontab originally created by root? what is the ownership of the crontabs in question?

What I would do is this:

as root

# crontab -l > cron.out
#chown : cron.out

Then as the user:

$ crontab cron.out

See if this works

Hope this helps

Chris

[Frank Slootweg]

> As , though, "crontab -"l" doesn't show anything, "crontab -e"
> doesn't allow me to edit my crontab and "crontab file" doesn't overwrite the crontab.

For each of these three scenario's, which (error) message(s) do you get?

[Jean-Louis Phelix]

hi,

It's possible to create crontab files for a given user even if this user is not allowed to use cron. Have a look to 'man crontab' fro explanation about crontab.allow and crontab.deny files.

Regards.

PS : in this case messages should be kind of "crontab: you are not authorized to use cron. Sorry."

[F. X. de Montgolfier]

Hi,

some precisions:

- the cron.allow file is correct, so the user should be able to use crontab.
- when removing the crontab of the user (as root), the user still cannot use the crontab command.
-I tried chmod -r 777 /var/spool/cron/crontabs to see if there would be any changes. There aren't any (and yes, I _did_ put back the correct rights afterwards ;-))
- there are no error messages
- the return code of calls to the crontab is 0

What I truly don't understand is that root can call crontab correctly, but not the other users. I'd think it was a problem of crontab not being able to call vi, but then why would it work for root?

Cheers,

Fran??ois-Xavier

[Frank Slootweg]

I advise to temporarily:

- Remove/rename /var/adm/cron/cron.allow
*and*
- Make an *empty*, i.e. 0 bytes, /var/adm/cron/cron.deny

That way, all non-root users should be able to use crontab(1) (see the crontab(1) manual page).

If that works, work from there.

[Sridhar Bhaskarla]

Hi,

I know it doesn't make sense but is a microsoft's idea.

Stop the cron. /sbin/init.d/cron stop
Remove the user files
mv /var/spool/cron/crontabs/USER /somewhere
Start the cron. /sbin/init.d/cron start
As a USER do, crontab -e

and see if it allows.

-Sri

[F. X. de Montgolfier]

Thanks for all the answers. I have to go onsite to have access to the system, thus will not be able to test the solutions and assign points before next thursday, but thanks for the help!

Fran??ois-Xavier

[F. X. de Montgolfier]

Okay, some updates:

I tried all of the above solutions, thinking that maybe I had not tried one, but so far no luck...

An additional precision: because of security issues, our server is configured with only 4 ports open:
port 22 is used for ssh connections
ftp, login and shell ports are restricted to localhost (using inetd.sec).
I would say this is the problem, but then why is root still able to use crontab -e?

Cheers,

FiX

[U.SivaKumar_2]

Hi,

DO this as root. problem will be solved.

#chmod +s /bin/crontab

regards,
U.SivaKumar

[F. X. de Montgolfier]

Hi,

I really thought chmoding might be the solution. unfortunately, no luck either...
my next try will be to try removing the inetd.sec file, and check whether crontab works again, but I have to unplug the computer from the network before being allowed to do so... I'll post again to the thread once I've tried it.

Cheers,

FiX

[F. X. de Montgolfier]

Okay, last status for this problem is the following one:

the user still cannot use crontab. But if I add another non-root user of the same group in the cron.allow file, everything works properly.
I created a new user, copied the profile files from the old user to the new, and checked that the new user could use crontab: it could...

in the end, I copied all the user's file to the new user, chowned them appropriately, checked that there was no problem with the new user, and destroyed the old one (after a back up, I may be stupid but I'm not _totally insane_ ).

I still don't have _any_ idea of why the old user could not use crontab, though...

FiX

[Judy Traynor]

Maybe its too late now - but check the value of the user's UMASK -

could be the user had this set so that he masked himself/herself out of the file once it was originally written.