cron runs scripts named xxxx.dpkg-old

I suppose cron could be smart about dpkg's files and ignore
them.

Or we could have a cronjob that cleans up cronjobs my marking
them chmod 0000.

Solution number two sounds rather smart. Simple and elegant.

On second thought, "chmod a-x" should be enough - unnecessary to touch the other permission bits.

Cron runs as root. Setting permissions won't help at all :)

Humm. I had the impression that the scripts should be _executable_ (i.e. have the x-bit set) in order for them to be executed. This _seems_ to be confirmed by http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/sysinit.html and a couple other pages. However, cron documentation does not mention this requirement, which is why I say "impression".

I tested it a few days ago just to be sure. chmod 0000 does not prevent
it from running.

The idea of cron being able to execute scripts that are not executable was bizarre enough that I had to verify it myself. On this machine, Kubuntu Breezy, removing the executable bits from a script in cron.{daily,monthly} with "sudo chmod a-x" _definitely_ prevents it from running - quite as would be expected.

Are you absolutely sure of your test results?

A simple test to verify cron's workings:
cd /etc/cron.hourly
sudo nano crontest

Insert the following two lines and save the file:
#!/bin/sh
date >> /tmp/crontest.log

sudo chmod a+x crontest
./crontest (to verify that the script works)

Now, open up a new terminal, and type "tail -f /tmp/crontest.log", and wait for the cron.hourly to execute at least once, to verify that cron works. (Optionally, if you know your cron works, skip this part and go directly to the next.)

Then, "sudo chmod a-x /etc/cron.hourly/crontest", and keep the "tail" open for a couple hours (or check back after that time), and see if the crontest script still got executed. (Note also that /tmp gets cleared at shutdown/startup.)

The files in /etc/cron.d (which is what the report is about) are not
scripts but crontabs.

My test was this crontab line:

* * * * * root date >> /tmp/date.log

And for sure ran after chmod 0000

Yay for vixie cron for making a difference between crontabs and scripts
when it comes to permission handling :/

Bah... my bad, sorry about that. :-)

Those files do appear in cron.hourly & company, too, and get run.

Alas, the bug title still stands, and it would be nice if this conflict could be solved.

This bug was fixed in the package cron - 3.0pl1-113ubuntu1

---------------
cron (3.0pl1-113ubuntu1) maverick; urgency=low

  * Merge from debian unstable. Fixes:
    - LP: #46493 (this should have been fixed way back in 3.0pl1-87, and I
      confirmed it is no longer a problem)
    - LP: #118168 (Debian #79037)
    - LP: #151231 (Debian #155109, #443615)
    - LP: #308341 (Debian #437180)
  * Remaining changes:
    - debian/control:
      + Build-Depends on debhelper >= 7.3.15ubuntu2, for Upstart
      + Drop MTA and lockfile-args to Suggests
    - add debian/cron.upstart
    - debian/postinst: remove calls to update-rc.d, invoke-rc.d and
      /etc/init.d/cron
    - debian/postrm: remove call to update-rc.d
    - debian/prerm: remove calls to invoke-rc.d and /etc/init.d/cron
    - debian/rules: install Upstart job
  * Drop the following changes, now in debian:
    - popen.c: check return code of initgroups() in cron_popen()
    - debian/control: add missing ${misc:Depends}
    - debian/control: Depends bump on lsb to >= 3.2.12ubuntu2. No longer
      required now that we use Upstart
    - debian/cron.pam: switch from including common-session to including
      the new common-session-noninteractive
    - pathnames.h: use sensible-editor

cron (3.0pl1-113) unstable; urgency=medium

  [ Christian Kastner / Javier Fernandez-Sanguino ]
  * debian/postinst:
    - Now that permissions and ownership of crontabs are changed unconditionally,
      do not attempt to chown user crontabs if none are present. Closes: #585636
    - Only change permissions if the crontabs directory exist

cron (3.0pl1-112) unstable; urgency=low

  [ Christian Kastner ]
  * do_command.c:
    - Don't send mail when a job exits non-zero, only send mail if the job sent
      output to stderr. This behaviour was introduced erroneously; while it
      does have merit, it is completly against standard cron behaviour.
      Closes: #581612
  * debian/compat:
    - Bumped debhelper compatibility to 7
  * debian/control:
    - Bumped Standards-Version to 3.8.4 (no change needed)
    - Build-Depend on debhelper (>= 7.0.50~)
    - Added dependency on ${misc:Depends} to package cron
  * debian/cron.init:
    - Changed Default-Stop from (1) to (empty). rc0 and rc6 were removed in
      3.0pl1-101 because the stop action -- sending SIGTERM/SIGKILL to cron
      on shutdown/reboot -- was redundant. This, however, also applies to
      rc1, because killprocs will do that for us.
  * debian/postinst:
    - Removed obsolete dpkg file backup code, this has been handed over to dpkg
      in 3.0pl1-109
    - Removed last remaining stop action (for rc1) from upate-rc.d (see above)
    - Add dpkg-statoverride for /usr/bin/crontab, and unconditionally change
      permissions of /var/spool/cron/crontabs. Closes: #304036, #460095
  * debian/standard.monthly:
    - Removed because it had been empty for years and therefore served no
      purpose
  * debian/cron.bug-{control,script}
    - Added to extend information submitted by reportbug
  * debian/rules:
    - Applied changes for standard.monthly and cron.bug-{control,script} above
  * debian/copyright:
    - Updated to reflect recent contribution...