Hallo,
ich möchte, dass ein Nutzer shell-Skripte starten kann, die root Rechte
benötigen. Ich möchte diesem Nutzer aber keine root Rechte einräumen.
Also habe ich mir folgendes überlegt: Der Nutzer soll die Ausführung nur
veranlassen, root führt sie dann selbst aus.
Quick & Dirty könnte das z.B. so laufen: der Nutzer erstellt eine Datei
in seinem home Verzeichnis. Root prüft regelmäßig, ob diese Datei
vorhanden ist. Wenn ja, wird das Skript ausgeführt und anschließend die
Datei gelöscht.
Das muss aber doch auch eleganter gehen. Ich bin aber kein Linux
Experte. Kann mir da jemand einen Tipp geben?
Danke!
Hannes
Hannes schrieb:> Das muss aber doch auch eleganter gehen.
geht auch.
Entweder mit sudo
https://de.wikipedia.org/wiki/Sudo
oder einfach bei dem script das das SUID flag setzen (könnte aber sein
das das bei scripten nicht mehr geht)
Peter II schrieb:> mit sudo
Der Nutzer soll keine root Rechte bekommen.
Es handelt sich um keine ausführbaren Dateien, sondern um shell und
python Skripte.
Hannes schrieb:> Peter II schrieb:>> mit sudo>> Der Nutzer soll keine root Rechte bekommen.>> Es handelt sich um keine ausführbaren Dateien, sondern um shell und> python Skripte.
hast du gelesen, was man mit sudo alles machen kann?
sudo ist tatsächlich umfangreicher als ich dachte...
sudo
sudo.conf
sudoers
sudoers.ldap
sudoreplay
visudo
sudo_plugin
...insgesamt 140 Seiten Doku.
Ich lese dann mal.
Gute Nacht
was ich in diesem forum nie verstehen werde ...
warum schreibt ihr ihm die eine zeilen nicht einfach hin und gut ist,
verweise auf docu wenn jemand eine frage stellt werde ich nie verstehen
...
1. suid auf scripte geht nicht, dann müsstest du den
interpreter suid setzen und das streichst du bitte
gleich aus deinem gehirn
2. ja, sudo ist das richtige mittel für dein problem
als bsp. hier mal das vorgehen auf ubuntu
1. alle benutzer die sudo verwenden sollen,
müssen in der gruppe 'sudo' sein
$> usermod -a -G sudo testbenutzer
2. in /etc/sudoers
testbenutzer ALL = NOPASSWD: /opt/huhu/meinScript1
ergebnis:
der benutzer "testbenutzer" darf das script ohne
passwortabfrage als root ausführen
Ray M. schrieb:> was ich in diesem forum nie verstehen werde ...> warum schreibt ihr ihm die eine zeilen nicht einfach hin und gut ist,> verweise auf docu wenn jemand eine frage stellt werde ich nie verstehen> ...>>> 1. suid auf scripte geht nicht, dann müsstest du den> interpreter suid setzen und das streichst du bitte> gleich aus deinem gehirn>> 2. ja, sudo ist das richtige mittel für dein problem>>> als bsp. hier mal das vorgehen auf ubuntu>> 1. alle benutzer die sudo verwenden sollen,> müssen in der gruppe 'sudo' sein>> $> usermod -a -G sudo testbenutzer>> 2. in /etc/sudoers>> testbenutzer ALL = NOPASSWD: /opt/huhu/meinScript1>>> ergebnis:> der benutzer "testbenutzer" darf das script ohne> passwortabfrage als root ausführen
kleine anmerkung noch am rande ...
scripte die du den usern so erlaubst als root auszuführen, sollten
immer root gehören und die rechte 700 besitzen !!!
$> chown root.root meinScript
$> chmod 700 meinScript
sonst könnte sie ein normaler user manipulieren und das willst du sicher
nicht haben ...
Ray M. schrieb:> was ich in diesem forum nie verstehen werde ...> warum schreibt ihr ihm die eine zeilen nicht einfach hin und gut ist,> verweise auf docu wenn jemand eine frage stellt werde ich nie verstehen
man nennt es "hilfe zur selbsthilfe". wenn man den leuten immer alles
vorkaut kommen sie immer wieder und fragen, wenn man ihnen dagegen sagt,
wie sie sich die lösung erarbeiten dann lernen sie auch den hintergrund.
Deine Lösung löst sein akutes problem, wenn er dann das nächste mal ein
problem hat was sich ähnlich lösen lässt dann kommt er wieder fragen,
wenn er aber dieses mal die doku gelesen hat, dann weiß er nächstes mal
schon was sudo kann.
Ray M. schrieb:> $> usermod -a -G sudo testbenutzer
Also das würde ich mit Sicherheit nicht machen.
Dadurch wird der Nutzer sudoer, d.h. er ist de facto root, denn meist
steht das folgende in /etc/sudoers:
1
# Allow members of group sudo to execute any command
2
%sudo ALL=(ALL:ALL) ALL
Hinterher Einschränken ist höchstens ein gut gemeinter aber
hoffnungsloser Versuch zur Schadensbegrenzung.
Es ist nicht notwendig Mitglied von wheel, sudo oder admin zu sein
wenn der Benutzer sudoer für bestimmte Befehle sein soll. Dazu reicht
ein entsprechend konfigurierter Eintrag in /etc/sudoers für eine
Benutzergruppe oder einen einzelnen Benutzer.
Insofern ist das mit den vorgekauten Lösungen also schon so eine Sache:
Nicht nur der Lerneffekt ist niedriger, man riskiert auch eine nicht
optimale Lösung.
Ray M. schrieb:> 1. alle benutzer die sudo verwenden sollen,> müssen in der gruppe 'sudo' sein>> $> usermod -a -G sudo testbenutzer
Möööp falsch. Besser mal die Doku lesen ;)
Effektiv ist das was du tun willst sehr schwer so zu erreichen dass es
danach igendwie sinnvoll sicher ist.
Was willst du denn effektiv erreichen, d.h. was soll der Benutzer tun
können? Sehr wahrscheinlich gibt es eine bessere Lösung, z.B. eine udev-
oder polikt-Einstellung, für das was du tun willst, als sudo oder suid.
Sven B. schrieb:> Effektiv ist das was du tun willst sehr schwer so zu erreichen dass es> danach igendwie sinnvoll sicher ist.
Halte ich für ein Gerücht, das ist kein neuzeitliches Problem.
Das oben genannte Beispiel
1
testbenutzer ALL = NOPASSWD: /opt/huhu/meinScript1
in /etc/sudoers ist hinreichend sicher, wenn man den Tipp mit den
Berechtigungen beachtet, also
1
sudo chmod a-rwx,u=rx /opt/huhu/meinScript1
2
sudo chown root:root /opt/huhu/meinScript1
da dann nur root das Script ändern kann.
Wenn man das ganze noch übertreiben will, kann man noch das
immutable-bit mit chattr setzen, wenn das Dateisystem das hergibt:
1
sudo chattr +i /opt/huhu/meinScript1
Grundsätzlich ist außerdem noch besser, man verzichtet auf NOPASSWD so
nicht zwingend notwendig, dann kann man auch sicher sein das derjenige
der gerade am PC sitzt auch derjenige ist, der sich ursprünglich
angemeldet hatte.
In jedem Script sollte man dann mindestens noch
1
PATH=/bin:/sbin:/usr/bin:/usr/sbin
vorgeben, damit da nix schiefgehen kann oder gleich absolute Pfade
nehmen.
Variablen vor der ersten Verwendung explizit zu initialisieren hat auch
noch nie geschadet und ist grundsätzlich guter Stil.
Ist letztendlich aber auch nur Zuckerguss:
Prinzipiell bereinigt sudo aber die Umgebungsvariablen vor dem Aufruf,
das kann und sollte man auch entsprechend erzwingen.
Polkit & co. sind bei weitem nicht auf allen Systemen verfügbar und/oder
sinnvoll, insbesondere auf Servern.
Kommt halt drauf an was das Skript macht. Generell muss sowas schon
recht sorgfältig geschrieben sein, sodass man ihm keine Eingaben geben
kann die irgendwas lustiges bewirken was so eigentlich nicht gedacht war
...
Ist natürlich auch die Frage, ob das hier überhaupt relevant ist, wenn
das ein privater Desktop-Rechner ist, ist das natürlich alles egal.
Liebe Leute,
es hat funktioniert. Natürlich war sie sudoers Datei der Schlüssel.
Danke an alle.
Das mit der Hilfestellung in Foren ist halt immer so eine Sache. Von
fertigen Lösungen bis hin zu "read the f** manual" liest man ja alles.
Der Hinweis auf "sudo" war im Nachhinein schon richtig, der Verweis auf
das Manual für meinen Geschmack etwas zu wenig. Aber als Fragesteller
kritisiere ich niemanden, der sich die Zeit für eine Antwort nimmt.
Wichtig ist mMn, dass man vom Forum eine Richtung gezeigt bekommt. Und
das hat ja dann super geklappt.
Danke nochmal und bis zum nächsten Mal!
hannes
Peter II schrieb:> oder einfach bei dem script das das SUID flag setzen (könnte aber sein> das das bei scripten nicht mehr geht)
Ging noch nie für Scripts. Weder unter Linux noch unter irgendeinem
anderen UNIX-Derivat.
Frank M. schrieb:> Ging noch nie für Scripts. Weder unter Linux noch unter irgendeinem> anderen UNIX-Derivat.
Wenn du es besser weist, dann solltest du den Wiki Eintrag ändern.
https://de.wikipedia.org/wiki/Setuid
[...]
Auf den meisten Systemen funktioniert dies nur für ausführbare
Binärdateien, nicht jedoch für interpretierte Scripts.
[...]
Peter II schrieb:>> Ging noch nie für Scripts. Weder unter Linux noch unter irgendeinem>> anderen UNIX-Derivat.>> Wenn du es besser weist, dann solltest du den Wiki Eintrag ändern.>> https://de.wikipedia.org/wiki/Setuid> [...]> Auf den meisten Systemen funktioniert dies nur für ausführbare> Binärdateien, nicht jedoch für interpretierte Scripts.> [...]
ähmm, wo ist jetzt der Unterschied zu Frank seiner Aussage?
tux schrieb:> ähmm, wo ist jetzt der Unterschied zu Frank seiner Aussage?
Ging noch nie für Scripts
ist wohl etwas anders als
Auf den meisten Systemen funktioniert
Hannes schrieb:> es hat funktioniert. Natürlich war sie sudoers Datei der Schlüssel.Hannes schrieb:> der Nutzer erstellt eine Datei
Wenn der Nutzer wirklich die Datei verändern können soll, frage ich mich
schon, ob das der richtige Weg ist. Zumindest falls der Plan umgesetzt
wurde, das ganze Skript mit sudo auszuführen.
LOL schrieb:> da dann nur root das Script ändern kann.
Da hast du was falsch verstanden, Steffen.
Er stellt sich das als Art Daemon Process vor und der Nutzer touch-ed
nur eine Datei, als eine Art "Flag" zur Ausführung.
Der Daemon sieht dann in etwa so aus:
[-f $user/run_script] && ./run_script.sh
(Wobei ich nicht mehr so firm in Shell bin, vermutlich ist die Syntaktik
der eckigen Klammern genauso falsch wie das -f für file exists)
Da wäre jedenfalls ein Sudo für die einzelne Datei besser bzw. je nach
Anwendungsfall wäre es einfacher das Skript non-root kompatibel zu
machen (z.B. Port > 1024)
Peter II schrieb:> Ging noch nie für Scripts>> ist wohl etwas anders als>> Auf den meisten Systemen funktioniert
Also ich kenne unter anderem:
UNIX System V
Unixware
ULTRIX
HP-UX
Solaris
AIX
SCO
SINIX
und einige der BSD-Derivate ziemlich genau, da ich seit 1984 mit
unixoiden Systemen arbeite.
Auf keiner dieser Plattformen wirkt ein suid-Bit für Scripts. Ob da
vielleicht irgendein exotisches Etwas, das UNIX-ähnlich aussieht, das
suid-Bit akzeptiert, kann ich selbstverständlich nicht ausschließen.
Aber ich halte dies für extrem unwahrscheinlich. Wahrscheinlich wollte
der Autor des Wikipedia-Artikels sich da ein Hintertürchen aufhalten -
aus verständlichen Gründen angesichts der Artenvielfalt, dies es bei
unixoiden System gibt.
Aber darauf pochen, dass es ein gibt, ohne eins nennen zu können, ist
wenig zielführend. Oder kennst Du ein Gegenbeispiel?
Frank M. schrieb:
[...]
> Aber darauf pochen, dass es ein gibt, ohne eins nennen zu können, ist> wenig zielführend. Oder kennst Du ein Gegenbeispiel?
Sieh dir mal http://www.in-ulm.de/~mascheck/various/shebang/#setuid an,
da werden ein paar Beispiele genannt.
Ich meine mich auch dunkel zu erinnern, daß das bei Linux mal ging und
erst mit Kernel 1.x irgendwann abgestellt wurde, aber das ist schon
etwas zu lange her um mich noch genau genug erinnern zu können.
Dein "das ging noch nie" ist daher definitiv falsch, es ist nur auf den
meisten Systemen nicht (mehr) möglich, SUID-Scripts zu nutzen. Aber es
ging früher mal.
