Warum kann cron in meinem Skript keine sudo-Dateien ausführen?

Ich habe ein Skript von einer Crontab eines nicht privilegierten Benutzers ausgeführt, das einige Befehle mit aufruft sudo. Außer es tut nicht. Das Skript läuft einwandfrei, aber die sudo'ed-Befehle schlagen unbemerkt fehl.

Das Skript läuft perfekt von einer Shell aus als der betreffende Benutzer.
Sudo benötigt kein Passwort. Der betreffende Benutzer hat (root) NOPASSWD: ALLZugriff gewährt in /etc/sudoers.
Cron läuft und führt das Skript aus. Durch Hinzufügen eines einfachen date > /tmp/logElements wird die Ausgabe zum richtigen Zeitpunkt erstellt.
Es ist kein Berechtigungsproblem. Wieder wird das Skript ausgeführt, nur nicht die sudo'ed-Befehle.
Es ist kein Pfadproblem. Wenn Sie envdas Skript ausführen, wird die richtige $PATHVariable angezeigt, die den Pfad zu sudo enthält. Es hilft nicht, es unter Verwendung eines vollständigen Pfads auszuführen. Der ausgeführte Befehl erhält den vollständigen Pfadnamen.
Der Versuch, die Ausgabe des Befehls sudo einschließlich STDERR zu erfassen, zeigt nichts Nützliches. Durch Hinzufügen sudo echo test 2>&1 > /tmp/logzum Skript wird ein leeres Protokoll erstellt.
Die Sudo-Binärdatei selbst wird einwandfrei ausgeführt und erkennt, dass sie Berechtigungen hat, auch wenn sie von cron im Skript ausgeführt wird. Das Hinzufügen sudo -l > /tmp/logzum Skript erzeugt die Ausgabe:

Der Benutzer ec2-user kann auf diesem Host die folgenden Befehle ausführen:
(root) NOPASSWD: ALL

Wenn Sie den Exit-Code des Befehls mit untersuchen $?, wird ein Fehler zurückgegeben (Exit-Code:) 1, aber es scheint kein Fehler zu vorliegen. Ein so einfacher Befehl /usr/bin/sudo /bin/echo testgibt denselben Fehlercode zurück.

Was könnte sonst noch los sein?

Dies ist eine kürzlich erstellte virtuelle Maschine, auf der das neueste Amazon Linux AMI ausgeführt wird. Die crontab gehört dem Benutzer ec2-userund die sudoers-Datei ist der Standard für die Verteilung.

sudo cron

— Caleb
quelle

Ich wollte über eine Lösung sprechen, aber dann las ich The user in question has (root) NOPASSWD: ALL access granted in /etc/sudoersund mein Gehirn begann zu laut zu schreien, um weiterzulesen.

— Shadur

@ Shadur: Sprich mit der Hand. Das ist auch nicht meine Art, eine Maschine einzurichten, aber diese Maschinen sind sofort einsatzbereit. Selbst wenn der Computer Ihnen gehört, erhalten Sie kein Root-Passwort. Ihr Schlüssel als Besitzer der Box wird in das ec2-Benutzerkonto eingegeben, das (wie bereits erwähnt) vollen sudo-Zugriff hat. Sie erhalten auch kein Passwort für ec2-user, es sei denn, Sie legen eines fest, es handelt sich um eine Anmeldung nur mit Schlüssel.

— Caleb

Als erstes würde ich empfehlen, einen separaten Benutzer mit eingeschränkten sudoRechten / nur / für die Befehle einzurichten, die Sie im Skript benötigen, und deren Anmeldefähigkeit vollständig zu deaktivieren.

— Shadur

Wenn Sie root haben und möchten, dass der Cron-Job als root ausgeführt wird, warum sollten Sie ihn dann in die crontab des ec2-Benutzers einfügen? Wäre Roots Crontab nicht passender? oder / etc / crontab?

— cas

@CraigSanders: Ich möchte nicht, dass der Cron-Job als root ausgeführt wird. Tatsächlich sollte der größte Teil davon als Benutzer ausgeführt werden. Die Frage betrifft nicht das Ausführen eines Jobs als root, sondern ein Skript, das über sudo speziell auf eine Funktion zugreifen kann.

— Caleb

Sudo hat einige spezielle Optionen in seiner Berechtigungsdatei, von denen eine eine Einschränkung der Verwendung für Shells zulässt, die in einem TTY ausgeführt werden, was Cron nicht ist.

In einigen Distributionen, einschließlich Amazon Linux AMI, ist dies standardmäßig aktiviert. Die /etc/sudoersDatei sieht ungefähr so aus:

# Disable "ssh hostname sudo <cmd>", because it will show the password in clear.
#         You have to run "ssh -t hostname sudo <cmd>".
#
Defaults    requiretty

#
# Refuse to run if unable to disable echo on the tty. This setting should also be
# changed in order to be able to use sudo without a tty. See requiretty above.
#
Defaults   !visiblepw

Wenn Sie die Ausgabe in STDERR auf der Ebene des Shell-Skripts statt des Befehls sudo selbst erfasst hätten, wäre Ihnen eine Meldung in etwa so vorgekommen:

Entschuldigung, Sie müssen ein tty haben, um sudo auszuführen

Die Lösung besteht darin, sudo die Ausführung in Nicht-TTY-Umgebungen zu ermöglichen, indem die folgenden Optionen entfernt oder auskommentiert werden:

#Defaults    requiretty
#Defaults   !visiblepw

— Caleb
quelle

Ich kann bestätigen, dass CentOS diese Einschränkungen hat.

— 12.