Warning messages from stat printed on installation with no user crontabs
Bug #1971895 reported by
Andrew Ruthven
This bug affects 3 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cron (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Rodrigo Figueiredo Zaiden | ||
Bionic |
Fix Released
|
Undecided
|
Rodrigo Figueiredo Zaiden |
Bug Description
On installation of cron on a new system, or (I expect) an upgrade with no user crontab files the following is printed:
Setting up cron (3.0pl1-
stat: cannot stat '*': No such file or directory
stat: cannot stat '*': No such file or directory
stat: cannot stat '*': No such file or directory
Warning: * is not a regular file!
This is related to the fix for CVE-2017-9525 introduced in 3.0pl1-
[ "$tab_name" = "*" ] && continue
We have observed this with Bionic, I haven't checked any other Ubuntu releases.
Cheers,
Andrew
CVE References
tags: | added: regression-security |
Changed in cron (Ubuntu Xenial): | |
status: | New → Triaged |
Changed in cron (Ubuntu Bionic): | |
status: | New → Triaged |
Changed in cron (Ubuntu Xenial): | |
assignee: | nobody → Rodrigo Figueiredo Zaiden (rodrigo-zaiden) |
Changed in cron (Ubuntu Bionic): | |
assignee: | nobody → Rodrigo Figueiredo Zaiden (rodrigo-zaiden) |
To post a comment you must log in.
I was just in the process of writing David Fernandez Gonzalez an Email about this problem when I came across this ticket.
I can confirm this problem on Ubuntu 18.04.6. My 20.x machines did not get the update, so I cannot verify on other releases:
Unpacking cron (3.0pl1- 128.1ubuntu1. 1) over (3.0pl1- 128.1ubuntu1) ... 128.1ubuntu1. 1) ...
Setting up cron (3.0pl1-
stat: cannot stat '*': No such file or directory
stat: cannot stat '*': No such file or directory
stat: cannot stat '*': No such file or directory
Warning: * is not a regular file!
Every single sysadmin should be concerned. ANY TIME we see asterisk wildcards being used in this fashion, where [ or test operators are behaving in this manner, we have reason to become concerned. To me, this smells of a shell script trying to parse crontab entries, which is inherently dangerous.
I am now questioning whether or not this postinst script potentially nuked something it shouldn't have.
How this was missed is beyond me.