cron runs scripts named xxxx.dpkg-old

Bug #46493 reported by Daniel Robitaille on 2006-05-25
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cron (Ubuntu)

Bug Description

Binary package hint: cron

bug initially reported using reportbug

---------- Forwarded message ----------
From: Gavin McCullagh <email address hidden>
To: Ubuntu Bug Tracking System <email address hidden>
Date: Mon, 10 Apr 2006 12:44:16 +0100
Subject: cron runs scripts named xxxx.dpkg-old
Package: cron
Version: 3.0pl1-87ubuntu2
Severity: normal

I'm not sure where this bug should really be filed, but I guess the
cron package maintainer will know. Debian packages (eg moodle, otrs)
which create files in /etc/cron.d/xxxx can in some instances upgrade
leaving /etc/cron.d/xxxx.dpkg-old files (or .dpkg-new). This causes
both script sets to be run.

It seems to me that this is a bug. Whether cron should blacklist
certain filenames in /etc/cron.d/ or whether dpkg should not place these
files in /etc/cron.d/ I am unsure. I thought I would raise it though.


-- System Information:
Debian Release: testing/unstable
 APT prefers breezy-updates
 APT policy: (500, 'breezy-updates'), (500, 'breezy-security'), (500, 'breezy')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-10-686-smp
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)

Versions of packages cron depends on:
ii adduser 3.64ubuntu1 Add and remove users and groups
ii debianutils 2.14.1-ubuntu2 Miscellaneous utilities specific t
ii libc6 2.3.5-1ubuntu12.5.10.1 GNU C Library: Shared libraries an
ii libpam0g 0.76-22ubuntu3 Pluggable Authentication Modules l

Versions of packages cron recommends:
ii postfix [mail-transport-a 2.2.4-1ubuntu2 A high-performance mail transport

-- no debconf information

Related branches

CVE References

Simon Law (sfllaw) wrote :

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

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

Changed in cron:
status: Unconfirmed → Confirmed
kko (kko) wrote :

Solution number two sounds rather smart. Simple and elegant.

kko (kko) wrote :

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 :)

kko (kko) wrote :

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 and a couple other pages. However, cron documentation does not mention this requirement, which is why I say "impression".

Dennis Kaarsemaker (dennis) wrote :

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

kko (kko) wrote :

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:
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.)

Dennis Kaarsemaker (dennis) wrote :

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 :/

kko (kko) wrote :

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.

Launchpad Janitor (janitor) wrote :
Download full text (11.3 KiB)

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
    - 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
  * 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...

Changed in cron (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers