By setting /etc/cron.allow and/or /etc/cron.deny it's possible to restrict what user is allowed to use crontabs to schedule a cron job to run as that user. At least at my office our SAs default to denying all non-root users the use of crontabs.

My question is why is this a useful default behavior? Scheduling jobs as a user seems a useful feature, especially since it may allow me to configure maintenance steps for a program I'm responsible for (and can log in to the managing user group for) without requesting/needing sudo permissions; thus limiting who needs to be handed elevated permissions.

So I'm wondering why crontabs isn't generally left usable by all users? What risk or security threat is opened by allowing a given user to run crontabs? It doesn't seem like it should lead to a possibility to elevate privileges, as the cron job will run as the user who scheduled it. It could be used to intentionally consume resources by starting a program every minute I suppose, but I don't see why this would be any more of a threat then a traditional forkbomb, which already have protections in place for.

So what is the motivation for preventing users from scheduling tasks with crontabs?

closed as primarily opinion-based by Rui F Ribeiro, Stephen Harris, Jeff Schaller, JigglyNaga, RalfFriedl Nov 8 '18 at 18:11

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    This seems like a question for your SAs ;-). – Stephen Kitt Nov 7 '18 at 19:57
  • 1
    Common to see dedicated app users (e.g. "prod-db1") be allowed to have crontabs, but personal accounts (e.g. "dsollen") to have it disabled. I guess it's to avoid folk introducing critical jobs that run as their own account, and if said account gets removed, or they leave, the whole place goes pop. – steve Nov 7 '18 at 20:29
  • 2
    Another reason is to force folk to use the enterprise's chosen scheduler product, e.g. Autosys / Tivoli etc, that gives ops proper visibility of jobs, their output, and ability to hold/reschedule/cancel them. – steve Nov 7 '18 at 20:32
  • @StephenKitt it would be, if I believed my SA had any clue. They are running hardening scripts dictated to them from the by the corporate gods without a clue of what the scripts do or why. They've had to ask me to explain their hardening scripts a few different times. – dsollen Nov 7 '18 at 21:07

Generally with security the idea is to reduce the surface area to only the required functions, aka turn everything off and only turn what is required back on again. As for what can go wrong... not much other than bugs and admin error, so as long as the admin knows they can add it to the list of things to keep tabs on.

Not the answer you're looking for? Browse other questions tagged or ask your own question.