Cockpit: nethserver-crontabmanager

Like a pirate I prefer to sink my boat before to fight, I have no return point now


if some of you would like to test and give feedbacks
please give it a try

for ns7.7 (last cockpit version)

  • should be workable for delegation
  • should be compatible with the nethgui versiion (each version should not break the last one)
  • should be translated at 98%
  • could be enhanced of course :smiley:

yum install

1 Like

Ran a quick test an it appears to work well: some fields with validation, cronjob created, mail to root working

Delegation works (expected: log cannot be viewed when delegated due to lack of user permissions; a word of warning to admins who trust users: delegated user can create cronjobs as anyone, including root, and therefore gain root access).


Admins shouldn’t be able to become root ATM. IIRC we didn’t implement Domain Admins as the “wheel” group.

It can change in the future though

So I’d forbid root impersonation by now.

1 Like

yep like the nethgui version you can create a cron job with any user you want, most of the cron job are running by root on the system


thank @davidep @dnutan

admins from domains admin are not in the wheel group but we do code to make them as in the wheel group :smiley:

Maybe I could think different

user root or user from domain admins group -> can set what user they want
other users must use their name as user of the cron.

Regarding user restriction, in advanced mode, beware of field concatenation/boundaries to build the cron job:

The time of the job: * * * * *
The user of the job: (space)
The command of the job: root /usr/bin/echo 'toto'

The time of the job: * * * * * root /usr/bin/echo
The user of the job: user
The command of the job: ; /usr/bin/echo 'tutu'


Thanks, we need some validators here, thinking on delegation, with cockpit I can test who is using the UI, I could display only the job of the authenticated user

yum install

  • Advanced settings (only for root and members of domain admins group)
  • The user of cron is forced to the authenticated user when it is not root or a members of domain admins group
  • The user can see only his cron, except if it is root of a members of the domain admins group

OK~. Advanced settings shown for root and domain admins but not for standard users. domain admins still can do about anything using cron jobs

It can be easily bypassed. Maybe you could show the disabled field but ignore its value and pass the logged-in user.
Another bypass method:
The command of the job: /usr/bin/echo 'bad boy'\n* * * * * root /usr/bin/evil

always talking about /etc/crontab (not user specific crontab in /var/spool/cron/)

OK. Seems good.

1 Like


quote=“dnutan, post:10, topic:13803”]
OK~. Advanced settings shown for root and domain admins but not for standard users. domain admins still can do about anything using cron jobs

yes domain admins can do most everything on your server, if you do not trust an human, you should never push him to this group. We could restrict the advanced mode to root if you think it is valuable


Please explain ?

I added now a validation inside the AdvancedUser, it was missing.

could you check the new version please

yum install

got it thank :smiley:

1 Like

Agree with you on human trust, I’m just pointing fingers for user’s awareness.
Restricting it would result in a more secure but less useful module. Better hear opinions of those whom have to delegate tasks.

no you are absolutely right, you pointed me in good direction, but now I will breack my head on the wall :smiley:

yum install

the user of cron is sanitized
the Cmd of the cron is sanitized :

  • cmd go to escapeshellcmd and \ are prohibited
  • root\s|admin\s|administrator\s are refused
  • ‘\n’ is refused
  • (\d-\d)\s or (\d,\d)\s are refused (no 0-5 
 0,5), no */5 due to escapeshellcmd

this will lead to block a lot of CL, we need to make a script and let the CL inside, then launch the script from the cron

Good! Now it’s working for that scenario.
The other bypass method I was referring to (disabled field) still works:


what solution we have ?

Do not show at all the USER field ?

My concern is that I cannot check during the validation step what is the user, we need to use a sudo delegation , during this step any user is seen as root, so any check will give back root and not the name of the user. Obviously during the web step (display the menu) the checks are done, do you are an admin, what is the name of the user for using it as the owner of the cron.


I don’t know how it works internally, but from what you say we cannot check against cockpit.user(), whoami and alike due to the delegation. :thinking:
From where do you obtain the username shown on the user field?

From a specific function in the vuejs page who does a whoami without sudo, but during the test phase we need sudo because we need to check if the name of the cron is not used (the db key).

Thinking on it, the simplest is to remove the User input when the user is not admin, and display the name as a simple string.

Das ist gut. :+1: