0

Currently, I have a script

install_crontab.py -u <user> -c <config>

This script takes care of installing cron job that runs as a given user. In my install_crontab script, I check (using sudo) if the user running the script has privileges over the user he is trying to install cron job for. If no, then the script fails. If yes, then it updates the crontab of a given user - crontab -u user1 -e

Now I am writing my own job scheduler (which does not use Unix cron but has its own in-memory queue and triggering mechanism). There are four components to this application,

  1. One Database (where job schedules are stored for all users).
  2. One schedule management service - RESTful service for DB read/write operations.
  3. 'n' scheduler services - one service per Unix user. This is responsible for actually triggering the job. It maintains an in-memory queue of jobs to trigger for the user this service is running as. The in-memory queue is refreshed periodically from the schedule information stored in the database.
  4. Installer interface (same install_crontab.py script).

Users use installer script for scheduling the job.

  • Installer script does auth-related validations by checking if the user running the script has privileges to the user he is trying to schedule the job for (using sudo checks).
  • The installer script then makes the REST call (instead of updating crontab) to the schedule management service. Schedule management service takes care of writing schedule and job-related information to the DB.

At the moment, I don't have auth related validation at the schedule management service layer. This is because I assume that the calls to the schedule management service are already authorized by the installer script. But I see there is a security loophole here, i.e. users can make direct REST calls to the schedule management service and install jobs that runs as some other users. How can I prevent this from happening? Note that I cannot run the schedule management service as the root user. But still, I want to build some auth layer to prevent this security loophole.

2
  • "One task-runner per user" could be simplified into a runner that is able to assume the identity of the user for which it is running a particular job. For convenience, the process could then end – thus triggering resource cleanup – and a new runner is then immediately spawned. Commented Feb 14, 2021 at 18:34
  • since permissions are purely based on the UNIX permissions model hence I am not sure if this is really possible unless the task-runner runs as root. Commented Feb 15, 2021 at 8:45

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.