So verwenden Sie Crontab, um ein Skript als Niemand auszuführen

24019
fixer1234

Dies ist auf einer CentOS-Maschine. Ich versuche, zu einem bestimmten Zeitpunkt jeden Tag ein Skript als Benutzer niemand (oder als Benutzer mit minimalen Berechtigungen) auszuführen. Hier ist niemand: 

[root@CentOS % ~] grep "^nobody" /etc/passwd  nobody:x:99:99:Nobody:/:/sbin/nologin

Folgendes habe ich in root's Crontab ausprobiert:

Setzen der Umgebungsvariablen SUDO_USER = nobody
15 17 * * * sudo -u nobody / bin / bash /usr/local/bin/bashscript.sh
15 17 * * * su -c /usr/local/bin/bashscript.sh nobody

Ich möchte den Eintrag für Crontab in Crontab von root beibehalten, wenn überhaupt möglich. Ich würde es auch vorziehen, mit dem Konto von niemandem zu täuschen, da ich nichts anderes brechen möchte, das auf diesen Einstellungen beruht. Ich bin nicht dagegen, ein anderes nicht privilegiertes Konto zu erstellen und ihnen eine echte Shell zu geben, wenn dies der entscheidende Punkt ist.

Ich gebe auch zu, etwas verblüfft zu sein. Ich würde davon ausgehen, dass dies ein alltägliches Problem sein würde, außer dass mein brauner Gürtel in Google-Fu nicht viel hilft.

3
Wie bestimmen Sie, ob das Skript unter niemand oder einem anderen Benutzer ausgeführt wird? Beide Wege arbeiten für mich. whitequark vor 14 Jahren 0
@whitequark - Das Skript erstellt eine Ausgabedatei, wenn sie ausgeführt wird. Es erstellt es in / tmp (wo ich davon ausgehe, dass der Benutzer "nobody" über Berechtigungen verfügt. vor 14 Jahren 0
Außerdem gibt es keine /etc/cron.d/crontab.allow oder /etc/cron.d/crontab.deny im System. vor 14 Jahren 0
Haben Sie es mit "su nobody" manuell ausgeführt? Haben Sie Cron-Protokolle geprüft (syslog-Ausgabe möglicherweise), nachdem es ausgeführt werden sollte? whitequark vor 14 Jahren 0
@whitequark - cron hat Protokolle? lass mich schauen Jan 21 18:25:01 `uname -n` crond [7776]: (root) CMD (su -c /usr/local/bin/bashscript.sh niemand) so root ist in diesen Klammern, also ist das wer lief das Skript Wenn Sie das auf der Kommandozeile ausführen, erhalten Sie die Meldung "Dieses Konto ist derzeit nicht verfügbar." b / c / etc / passwd ist auf nologin eingestellt vor 14 Jahren 0
@whitequark sudo -u nobody /usr/local/bin/bashscript.sh funktioniert von der root-Eingabeaufforderung aus, lassen Sie mich es erneut von crontab ausführen und schauen Sie sich die Protokolle an ... vor 14 Jahren 0
@whitequark (crontab line zuerst, log line 2 [redacted]) 18 19 * * * sudo -u niemand /usr/local/bin/script.sh 21. Januar 19:18:01 fakeame crond [14653]: (root) CMD (sudo -u nobody /usr/local/bin/script.sh) hat die Ausgabedatei nicht erstellt, funktioniert jedoch über die Befehlszeile OK vor 14 Jahren 0
25 19 * * * sudo -u pica / bin / bash /usr/local/bin/bashscript.sh (das als mein Konto ausgeführt wird, ein aktives Konto, das sudo verwenden kann, funktionierte nicht in crontab, funktionierte aber wieder mit dem root-Befehl Linie) vor 14 Jahren 0

5 Antworten auf die Frage

6
Simon Lindgren

Ich vermute, du postest den Inhalt von crontab -eoder crontab -l?

Dies ist die Crontab-Datei, die auf den Benutzer "root" verweist, und diese Datei unterstützt nicht die Angabe eines Benutzers, der den Befehl als ausführt (da es sich normalerweise um eine Datei handelt, die zum Planen persönlicher Jobs verwendet wird).
Schauen Sie sich /etc/crontabstattdessen an, welche systemweite crontab ist und ein zusätzliches Feld hat: das Benutzerfeld . Fügen Sie eine Zeile wie folgt hinzu /etc/crontab:

15 17 * * * nobody /usr/local/bin/bashscript.sh
Bestehende Praktiken, die ich überall gesehen habe, sind die täglichen Wartungsarbeiten in der Crontab von root. Ich denke, das ist eine schlechte Praxis, da es ein Feld gibt, in dem der Benutzer den Cronjob ausführen kann. Ich habe noch nie zuvor von / etc / crontab gehört. Dies ist eine bessere Antwort als meine Problemumgehung. vor 14 Jahren 0
Eigentlich scheint /etc/cron.d/ der bevorzugte Ort gegenüber / etc / crontab zu sein. Die Ubuntu-Dokumentation besagt, dass / etc / crontab von Updates betroffen sein könnte. vor 14 Jahren 3
2
Kitty

su --shell = / bin / bash --session-command = "/ path / to / command -argument = etwas" Benutzername &

Funktioniert für mich und wirft nicht den "Dieses Konto ist derzeit nicht verfügbar." Fehler, auch wenn der Benutzer keine gültige Login-Shell hat

1

Eigentlich führe Clawloon mich zur Antwort, aber lassen Sie mich meine eigene, umfassendere Antwort erstellen, damit sie nach oben schweben kann.

Ich weiß nicht, wie üblich es ist, aber einige Online-Ubuntu-Dokumentation besagt, dass / etc / crontab beim Upgrade überschrieben werden kann. Die bevorzugte Lösung ist das Erstellen einer Datei mit dem Namen /etc/cron.d/anything (wo alles sein kann) (alles gut. Jeder Dateiname)

Ich habe eine Datei mit dem Namen /etc/cron.d/nobody erstellt und setze die Skripts als nicht privilegierten Benutzer ein. Beispielzeilen:

# run the following every day at 01:02 AM 02 01 * * * nobody /usr/local/bin/script-to-run-as-nobody.sh

Ich habe einen Kommentar in root's Crontab eingefügt, den andere verfolgen können, da die täglichen Crontab-Jobs derzeit alle von dort ausgeführt werden. Nicht gerade die beste Praxis.

Zu Testzwecken muss ich den Job zuerst über die Befehlszeile ausführen. Da ich Sudo-Privilegien habe, verwende ich:

$ sudo -u root sudo -u nobody /usr/local/bin/script-to-run-as-nobody.sh

Wenn dieses Skript in / dev / stderr oder / dev / stdout ausgegeben werden muss, gehen Sie wie folgt vor:

$ chmod o+w /dev/ttyp1

und mache ein:

$ chmod o-w /dev/ttyp1

Wenn Sie mit dem Testen fertig sind, verhindern Sie, dass nur jemand Junk an den Bildschirm Ihres Terminals sendet. (Das tatsächliche Terminal, das Sie verwenden, kann sich von / dev / tty1 unterscheiden. Verwenden Sie daher einen $ ls -ltr / dev / tty * | grep-Benutzernamen, um herauszufinden, welcher der von Ihnen ist.)

0

Problemumgehung statt einer echten Antwort:

Sie können einen Kommentar zu Ihrer Crontab hinzufügen

**#see crontab -u nobody -l for something that runs everyday at 1:15 AM**

und fügen Sie dem Benutzer "nobody" crontab einfach einen Eintrag hinzu. Ich benutzte:

**15 1 * * * /usr/local/bin/script.sh #comment**
0

Abhilfemaßnahme # 2

Sie können einen nicht privilegierten Benutzer mit einer Login-Shell in / etc / passwd erstellen

sagen Sie, erstellen Sie einen Benutzer mit dem Namen "jemand", verweigern Sie diesen Sudo, geben Sie ihm jedoch eine Shell

Dann sollte folgendes in Crontab von root funktionieren:

15 1 * * * su -c /usr/local/bin/bashscript.sh somebody

Ich mag die Antwort von Clawspoon / etc / crontab besser.

Verwandte Probleme