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?
Hannes schrieb: >> mit sudo > > Der Nutzer soll keine root Rechte bekommen. Also mit sudo Einfach mal die Doku lesen.
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 ...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Als Alternative möchte ich noch super in den Rqum stellen. http://www.ucolick.org/~will/RUE/super/super.1.html Gruß Roland
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.