Init script per shell als regulärer user starten

Chaser · 24 Feb. 2013

Hallo,

ich habe eine Frage bezüglich Shellprogrammierung. Muss mich im Rahmen eines Projektes in die Materie einarbeiten, ist eigentlcih kompletter Neuling was Shell-Skripts unter Linux angeht. Wäre für hilfe Dankbar.

Ich möchte mittels Shell-Script den Status (service <Dienstname> staus) meiner NMS-Software abrufen lassen und die Ausgabe als Mail versenden.
Dies soll automatisch als Cronk-Job in festgelegten Abständen erfolgen.

Das Problem ist die NMS Software soll den Cron-Job bzw. das Skript selbstständig ausführen.

Der User der NMS Software hat nur beschränkte Berechtigungen.

1. Ist es möglich dass dieser User über das Skript den Befehl (service <Dienstname> staus) ausführen darf obwohl er kein Root.

2. Kann der beschränkte NMS User den Cron-Job automatisch starten oder könnte dies ebenfalls an den mangelnden Berechtigungen scheitern.

Danke für die hilfe im voraus.

abgdf · 24 Feb. 2013

Zerleg' Dein Problem in mehrere Teile. Z.B.

Chaser schrieb:
1. Ist es möglich dass dieser User über das Skript den Befehl (service <Dienstname> staus) ausführen darf obwohl er kein Root.

Warum probierst Du das nicht aus?

Phillinger · 24 Feb. 2013

Chaser schrieb:
Der User der NMS Software hat nur beschränkte Berechtigungen.

1. Ist es möglich dass dieser User über das Skript den Befehl (service <Dienstname> staus) ausführen darf obwohl er kein Root.

Ja. service ist in /usr/sbin und damit nicht in der $PATH-Variablen des Users. Daher wird es nicht ausgeführt, wenn man es als User eingibt. Mit vollständiger Pfadangabe klappt das. Also hier /usr/sbin/service <Dienstname> status

Übrigens: Mit dem Befehl which bekommt man den Pfad eines Befehls heraus. Hier also auf der Konsole (als root wg. $PATH):

Code:

# which service
/usr/sbin/service

Chaser schrieb:
2. Kann der beschränkte NMS User den Cron-Job automatisch starten oder könnte dies ebenfalls an den mangelnden Berechtigungen scheitern.

Ein cron-Job muss als root angelegt werden, man kann aber angeben, als welcher User der auszuführende Befehl ausgeführt werden soll. In der /etc/crontab sähe ein Eintrag so aus:

Code:

#m  h dom mon dow user            command
15  *   *   *   * USER /usr/bin/DeinSkript.sh

So wird immer in der 15. Minute (m) in jeder (*) Stunde (h), jedem Tag des Monats (dom), jeden Monat (mon) und jeden Tag in der Woche (dow) von User "USER" das Skript /usr/bin/DeinSkript.sh aus. In das Skript kannst du dann alles rein packen um die Ausgabe von /usr/sbin/service <Service> status per Email abzuschicken, z.B. mit sendEmail.

Chaser · 25 Feb. 2013

Hallo,

beim which Befehl bekomme ich folgende Ausgabe:

Code:

which service
/sbin/service

Hab mein Skript entsprechend geändert:

Code:

status=`/sbin/service icinga status`

Beim Ausführen des Skriptes bekomm ich immer noch eine Fehlermeldung:

Code:

> sh check_alive.sh
service: only root can use service
> service: only root can use service
sh: service:: command not found

Phillinger · 25 Feb. 2013

Hm, ich hatte mein Posting nebenher anhand eines Debian-Systems geprüft. Möglich, das service in anderen Distributionen andere Zugriffsrechte hat - so wie bei dir.

/sbin beinhaltet ausschließlich Programme, die nur von root ausgeführt werden dürfen (superuser binaries). Tipp mal bitte ls -l /sbin/service in die Konsole, dann siehst du die Zugriffsbits und den Besitzer sowie die Gruppe des Programms service. Wenn du damit nichts anfangen kannst, poste das Ergebnis einfach mal, dann erkläre ich es dir.

Zu deinem eigentlichen Problem: Wenn du keinen root-Zugriff auf die Kiste hast, ist hier jetzt Feierabend. Wenn du root-Zugriff hast, kannst du entweder root dein Skript ausführen lassen (in die crontab als User root angeben) oder mit Setuid service auch für Normalo-User ausführbar machen. Beides hat (wie alles, was mit root zu tun hat) sicherheitsrelevante Fußangeln, die beachtet werden sollten.

Chaser · 25 Feb. 2013

Danke für den Hinweis.

spoensche · 25 Feb. 2013

Kurze und hoffentlich verständl. Zusammenfassung (ich verkompliziere es gern mal):

Alles was mit Init, Initscript und Systemstart zu tun hat ist nichts für den normalen User, sondern root only.
Ein normaler User hat, schon der Sicherheit wegen,, keine Systemdienste zu starten, geschweige den globale Systemkonfigurationen, wie z.B, inititalisieren von Hardware etc, vorzunehmen.
Die laufenden Dienste werden auch nicht mit root Rechten ausgeführt, sondern mit den Rechten des jeweiligen Systemusers, z.B. wird MySQL vom User mysql ausgeführt.

Das hat folgenden Hintergrund:
Wenn z.B. MySQL mit root Rechten laufen würde und es einem Angreifer gelingt durch einen Bug o.ä in MySQL das System zu kompromitieren, hat er somit auch vollen root Zugriff. Wenn MySQL allerdings mit einem eigenen User und damit mit eingeschränkten Berechtigungen läuft hat der Angreifer "nur" eingeschränkten Zugriff.

towo · 25 Feb. 2013

Code:

~
towo:Defiant> service samba status
[ ok ] nmbd is running.
[ ok ] smbd is running.

~
towo:Defiant> service samba stop
[....] Stopping Samba daemons: nmbdstart-stop-daemon: warning: failed to kill 3504: Operation not permitted
 smbdstart-stop-daemon: warning: failed to kill 3523: Operation not permitted
. ok 

~
towo:Defiant>

Ergo hat das erstmal nichts mit Sicherheitsbedenken zu tun, weil eine Statusabfrage absolut nichts verändert.

Herz-von-Hessen · 25 Feb. 2013

Hallo Chaser,

Chaser schrieb:
Ich möchte mittels Shell-Script den Status (service <Dienstname> staus) meiner NMS-Software abrufen lassen und die Ausgabe als Mail versenden.
Dies soll automatisch als Cronk-Job in festgelegten Abständen erfolgen.

Zu Cron habe ich das hier.
Das Problem ist die NMS Software soll den Cron-Job bzw. das Skript selbstständig ausführen.

Chaser schrieb:
Der User der NMS Software hat nur beschränkte Berechtigungen.

Code:

man sudo

Und ein Blick in die /etc/sudoers

Chaser schrieb:
1. Ist es möglich dass dieser User über das Skript den Befehl (service <Dienstname> staus) ausführen darf obwohl er kein Root.

Ja

Chaser schrieb:
2. Kann der beschränkte NMS User den Cron-Job automatisch starten oder könnte dies ebenfalls an den mangelnden Berechtigungen scheitern.

Kein User startet einen Cronjob, den startet das System mit den entsprechenden Rechten.

Lieben Gruß aus Hessen

panamajo · 25 Feb. 2013

Phillinger schrieb:
Ein cron-Job muss als root angelegt werden,

Quatsch

Phillinger schrieb:
man kann aber angeben, als welcher User der auszuführende Befehl ausgeführt werden soll.

Das ist eine mögliche, aber absolut abzuratende Art cronjobs einzurichten.

Cronjobs funktionieren wunderbar auch für einfache User. Wenns unbedingt priviligiert sein muss dann ist es ebenfalls die bessere Wahl den conjob per

Code:

crontab -e

als ebendieser priviligierte User einzurichten.

Phillinger · 26 Feb. 2013

panamajo schrieb:
Phillinger schrieb:

Ein cron-Job muss als root angelegt werden,

Zum Vergrößern anklicken....

Quatsch

Stimmt. Da ich bisher nur cronjobs mit root-Rechten erstellen musste, hatte ich da einen Tunnelblick.

panamajo schrieb:
Phillinger schrieb:

man kann aber angeben, als welcher User der auszuführende Befehl ausgeführt werden soll.

Zum Vergrößern anklicken....

Das ist eine mögliche, aber absolut abzuratende Art cronjobs einzurichten.

Warum ist davon absolut abzuraten?

panamajo schrieb:
Wenns unbedingt priviligiert sein muss dann ist es ebenfalls die bessere Wahl den conjob per

Code:

crontab -e

als ebendieser priviligierte User einzurichten.

Warum?

panamajo · 26 Feb. 2013

Phillinger schrieb:
panamajo schrieb:

Das ist eine mögliche, aber absolut abzuratende Art cronjobs einzurichten.

Zum Vergrößern anklicken....

Warum ist davon absolut abzuraten?

panamajo schrieb:

Wenns unbedingt priviligiert sein muss dann ist es ebenfalls die bessere Wahl den conjob per

Code:

crontab -e

als ebendieser priviligierte User einzurichten.

Zum Vergrößern anklicken....

Warum?

Weil es anders gedacht ist. cron implementiert eine Lösung für die Problemstellung wie man auf einem Multiuser/-tasking System zeitlich getriggerte Aufgaben einrichten kann, und zwar ohne Kollisionen und Rechteeskalationen zu riskieren. Dazu wird eine Abstaktionsebene um die internen Funktionen geschaffen, d.h. für einen normalen User ist es egal ob sein crontab in /var/spool/cron/tabs gespeichert wird oder woanders, er startet per crontab -e seinen Lieblingseditor und konfiguriert den Kram.

Wenn du jetzt direkt /etc/crontab (oder Dateien in /etc/cron.*) änderst umgehst du die Abstaktionsebene, was so nicht vorgesehen ist. Beim nächten Systemupgrade wird alles in diesen Dateien überschrieben werden.
Dazu kommen Kollisionsprobleme, z.B. Admin A editiert gerade /etc/crontab um das Backup auf Dateisystemebene einzurichten, Admin B editiert dieselbe Datei wg. irgendwas anderem - wer gewinnt? Jedenfalls nicht beide...

Phillinger · 26 Feb. 2013

Kapiert. Und schon wieder was gelernt. Vielen Dank für die ausführliche Antwort!

Init script per shell als regulärer user starten

Chaser

Newbie

abgdf

Guru

Phillinger

Member

Chaser

Newbie

Phillinger

Member

Chaser

Newbie

spoensche

Moderator

towo

Moderator

Herz-von-Hessen

Guru

panamajo

Guru

Phillinger

Member

panamajo

Guru

Phillinger

Member