On Mon, 20 Mar 2006, C. Ray Ng wrote:

> Stephan Wiesand wrote:
>>  One incompatible change is that the new version doesn't accept files with
>>  mode 755 in /etc/cron.d (like on SL4). The message is however "BAD FILE
>>  MODE". What modes are acceptable isn't documented, but 644 works. The
>>  reason for this change is beyond me...
>
> Most of the files in /etc/cron.*ly/ are still with mode 755 as set
> in the individual rpm packages. They do work fine on SL4 with 
> vixie-cron-4.1-36.EL4.

Those files arn't read directly by crond but are processed by run-parts as 
a result of lines like:

   02 4 * * * root run-parts /etc/cron.daily

in /etc/crontab etc etc.

The code which objects to permissions on crontabs (/etc/crontab, 
/etc/cron.d/*, AND (of course) user crontabs), seems to be in database.c 
process_crontab():

 	if ( PermitAnyCrontab == 0 )
 	{
...
 	    if ((statbuf->st_mode & 07533) != 0400) {
 		    log_it(fname, getpid(), "BAD FILE MODE", tabname);
 		    goto next_crontab;
 	    }
...
         }

so it can't be writable by anyone other than the owner or executable by 
anyone.

Note that this is ACTUALLY more permissive than in the code from the tar 
(real upstream), there are patches changing this in the specfile and the 
original code was apparently:

 	    if ((statbuf->st_mode & 07777) != 0600) {
 		    log_it(fname, getpid(), "BAD FILE MODE", tabname);
 		    goto next_crontab;
 	    }

which is probably even more braindead (you can't have it world readable 
and it MUST be writable by the owner!!!).  The processing of /etc/cron.d/ 
might have been added in another patch though so this code might have 
originally only been used for user crontabs...

I personally think that changing it to:

 	    if ((statbuf->st_mode & 07422) != 0400) {
 		    log_it(fname, getpid(), "BAD FILE MODE", tabname);
 		    goto next_crontab;
 	    }

would be fine, but you would probably have to pursuade The Upstream Vendor 
that the change caused significant problems.  After all what reason is 
there for a crontab file being executable...  And do any packages etc 
actually include anything in /etc/cron.d/ (yet)?

> We did try to chmod on all files in /etc/cron.*ly/* and restart crond on
> the SL3 node, but that didn't work for us.
>
> The "Pemission denied" messages in the log were also come from the
> /etc/cron.hourly/ which we don't have any file in there.

That seems somewhat unlikely given that crond doesn't look in there.  Can 
you replicate it?  Of course it *might* be an error from run-parts but if 
the directory is empty that is probably a bug.

Of course if /etc/cron.hourly/ is empty then one can also comment out the 
relevant /etc/crontab line -- we do this since we don't want a null cron 
job starting every hour...

-- 
Jon Peatfield,  Computer Officer,  DAMTP,  University of Cambridge
Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/