Restrict crontab für normale User

  • Themenstarter Themenstarter Anonymouse
  • Beginndatum Beginndatum
A

Anonymouse

Guest
Ich versuche gerade die Ausführung von cronjobs bzw. die Nuztung von crontab für normale User zu unterbinden.

In der manpage von Debian Jessie (Testing) steht bei crontab hierzu:
If the cron.allow file exists, then you must be listed therein in order to be allowed to use this command. If the cron.allow file does not exist but the cron.deny file does exist, then you must not be listed in the cron.deny file in order to use this command. If neither of these files exists, only the super user will be allowed to use this command.

Ich habe Folgendes versucht:
touch /etc/cron.allow
chmod 600 /etc/cron.allow
(Kein Inhalt)

Und:
touch /etc/cron.allow
chmod 600 /etc/cron.allow
awk -F: '{print $1}' /etc/passwd | grep -v root > /etc/cron.deny

Egal welche Variante. User können noch immer crontab -e bzw. crontab -l usw. nutzen, um sich neue crons anzulegen.

Hat jemand eine Idee?
 
Das bringt leider nichts. Hier direkt von der Man-Pages des betroffenen Systems:

If the /etc/cron.allow file exists, then you must be listed (one user per line) therein in order to be allowed to use this command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does exist, then you must not be listed in the /etc/cron.deny file in order to use this command.
 
Meine Überlegungen dazu:

* /etc/cron.allow darf nur alleine stehen. Es darf keine deny gleichzeitig geben! wenn ich die "leer" anlegen will schreibe ich immer nur "root" rein...
* Muss der User sich abmelden und anmelden, damit die neuen "Berechtigungen" greifen?
* ...
 
Ich habe derzeit nur die cron.allow angelegt und auch schonmal root eingetragen.

Trotz abmelden, Neustarts. Nichts. Sehr komisch...
 
Soweit ich informiert bin, verhindern/erlauben die cron.deny/cron.allow nicht das Anlegen von Cronjobs (crontab) sondern deren Ausführung (cron/crond). Wenn du nicht willst, dass User Crontabs anlegen können, dann restrikte die /usr/bin/crontab entsprechend über die Dateirechte und sorge dafür, dass die User in /var/spool/cron/ keine Dateien anlegen können.
 
M.E.n. sollten die User grundsätzlich keine Cronjobs anlegen/starten dürfen, wenn die Dateien cron.allow & cron.deny vorhanden sind.

Sind die o.g. Dateien nicht vorhanden, so darf eigtl. nur root Cronjobs anlegen/starten.

Ansonsten den Weg mit der /etc/cron.deny versuchen, welches besser greifen sollte als die /etc/cron.allow

Denke dran, es darf keinen Whitespace in den Files geben.
 
bitmuncher hat gesagt.:
Soweit ich informiert bin, verhindern/erlauben die cron.deny/cron.allow nicht das Anlegen von Cronjobs (crontab) sondern deren Ausführung (cron/crond). Wenn du nicht willst, dass User Crontabs anlegen können, dann restrikte die /usr/bin/crontab entsprechend über die Dateirechte und sorge dafür, dass die User in /var/spool/cron/ keine Dateien anlegen können.
Zum Vergrößern anklicken....

Selbst das anlegen dürfte nicht funktionieren.
Ich habe zum Test einen cron angelegt und der wird immer brav ausgeführt. ;)

Keine Ahnung wo das Problem liegt, habe jetzt mal an die Debian Liste geschrieben. Eventuell ist es ein Bug oder eine nicht aufgelöste Paketabhänigkeit.
 
Es ist gelöst, auch wenn ich damit nicht zufrieden bin...

Die Datei cron.allow muss für die User auch lesbar sein. Also ein »chmod o=r /etc/cron.allow« drauf.

Irgendwie logisch, aber dann doch wieder seltsam. Den Zugriff auf cron bzw. crontab sollte man mit einem anderen Berechtigungskonzept lösen, so hinterlässt es einen faden Beigeschmack. (jedenfalls bei mir)
 
chr0n0s hat gesagt.:
M.E.n. sollten die User grundsätzlich keine Cronjobs anlegen/starten dürfen, wenn die Dateien cron.allow & cron.deny vorhanden sind.

Sind die o.g. Dateien nicht vorhanden, so darf eigtl. nur root Cronjobs anlegen/starten.

Ansonsten den Weg mit der /etc/cron.deny versuchen, welches besser greifen sollte als die /etc/cron.allow

Denke dran, es darf keinen Whitespace in den Files geben.
Zum Vergrößern anklicken....

Ich verstehe die Aufregung nicht. Es ist völlig normal, dass auch User Cronjobs anlegen dürfen. Genau wie jeder Benutzer grundsätzlich auch Prozesse starten darf (halt nur nicht alle).
Es gibt dafür im Prinzip mehrere Konfigurations-Orte. Zum Einen unter /etc/cron.d, /etc/cron.daily, usw. und dann noch die crontabs unter /var/spool/cron/crontabs/. Diese Crontabs unterhalb von /var/spool/cron/crontabs/ heißen wie der Benutzer und werden dann auch nur unter dieser Benutzerkennung ausgeführt (siehe Manpage). Und solange man nicht mit cron.deny und cron.allow arbeitet oder die Ausführungsrechte von /usr/bin/crontab für Gott und die Welt entfernt, kann jeder User nach belieben crontabs anlegen.

Aber warum soll das plötzlich ein Problem sein? Ein Multiuser-System sollte i.d.R. so eingerichtet sein, dass wichtige Aktionen protokolliert werden, Zugriffsbeschränkungen auf sensible Bereiche bestehen und auch die Ressourcen limitiert sind. Unter den Gesichtspunkten macht's keinen Unterschied ob ein User 24 Stunden lang eingeloggt ist und jede Sekunde ein Programm von Hand startet oder ob das ein Cronjob unter seiner Benutzerkennung macht.
 
Meinen ersten Satz hast Du, glaube ich, missverstanden.

Ich bezog das rein auf die Art, wie es sich mit den Cronjobs verhält. Ich habe damit keine Meinung vertreten, ob das User dürfen oder nicht. Das muss jeder selbst wissen und anhand seiner (Unternehmens-) Anforderungen entscheiden.

Unsere Systeme sind da relativ offen, was das Anlegen von Cronjobs/Tasks angeht.

Viel gerede um nichts, habe nur versucht dem Threadersteller zu vermitteln, anhand welcher Kriterien Cronjobs von wem angelegt/ausgeführt werden dürfen und keine allgemeine Meinung vertreten ;)
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben