Hello Brandon, I wasn't able to use an untrusted user account to induce this behaviour. So, I'm making this bug public so that more people can be made aware of the misconfiguration that is being encouraged.
It's unfortunate that the providers of this advice never actually tested it themselves. It's unfortunate that the cron manpages don't detail proper permissions for these files. It's unfortunate that crontab(1) doesn't perform this access control check while it has root privileges. It's perhaps most especially unfortunate that this check isn't actually performed by cron(8) at all -- a user listed in /etc/cron.deny isn't actually denied running cron jobs, but is denied managing cron jobs. Existing configurations would keep working. (Probably this is not news to most sysadmins but I'd long since forgotten this detail.) So now, the question is what remediation do we take? - adjusting cron(8) feels like a good idea but would take a fair chunk of effort to not be silly about the implementation. It might also break configurations using the 'gatekeeping' feature of crontab(1). - adjusting crontab(1). I'm not sure how much work this would take but feels like a good approach. - fixing the manpages to describe the correct permissions. This feels like a good idea regardless of changes we may make to crontab(1). Thanks -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1813833 Title: User without read permission on cron.allow can execute crontab To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1813833/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
