Hi.

Viele Programme verlangen sudo. Oft braucht man aber nur eine kleine Funktion in einem Skript, das man aber nicht gleich mit sudo laufen lassen möchte.

Zb habe ich gerade ein Skript, indem ich etwas mounten will, aber deswegen nicht gleich sudo eingeben möchte.

Wie kann man das machen?

MfG

Also wenn Du den Benutzer etwas einhängen lassen willst, solltest Du lieber einen entsprechenden Eintrag in der fstab machen. Dort kannst Du für eine bestimmte Partition allen Nutzern das Recht geben, diese einzuhängen.

Danke. Für mount wäre das Problem für mich gelöst.

Aber angenommen als übertriebenes Beispiel ich möchte einem User nur den Befehl ls -l erlauben, aber nicht den Befehl ls oder ls -a.

Wie ginge das? Meine Idee wäre eigentlich gewesen, dass ich ein Skript schreibe, indem einfach nur ls -l steht. Dieses wollte ich für den User ausführbar machen. Aber dann bemerkte ich, dass ls -l ja auf ls basiert, welches man dann wiederum verbieten müsste, wenn man es nicht einsetzen darf, wodurch man aber auch kein ls -l einsetzen darf. Darauf hin dachte ich mir, dass ls nur von Usern der Gruppe lsgruppe benutzt werden dürte. Dann könnte der normale Benutzer ls nicht mehr selber ausführen, wäre auf das Skript angewiesen, welches er mit sudo und einem Benutzer aus der lsgruppe ausführen müssten. Aber dann fiel mir auf, dass man mit sudo ja auch wieder das normale ls ausführen könnte.

De einzige Lösung, die ich nun sehe, wäre ls neukompilieren, wo nur noch die gewünschten Optionen erlaubt sind.

Ginge es vielleicht einfacher?

MfG

Lass das mit dem neu kompilieren. Der erste Ansatz war richtig:

Schreibe ein Shellscript, welches folgenden Inhalt hat:

#!/bin/sh

echo $(ls -l -- $*)

Dabei werden die Parameter des Skriptes an ls -l weitergegeben, wobei weitere Argumente wie -a etc. ignoriert werden.

Dieses machst du dann über die sudoers mit sudo, aber ohne Passwort zugänglich.

Schau dir mal PolicyKit an. (Das wird aber keine Lösung für dein imaginäres ls Problem sein.)

Danke sehr. PolicyKit werde ich mir später noch genauer anschauen. Erstmal interessiert mich die Skriptklösung.

Diese habe ich noch nicht ganz verstanden.

Das -- sorgt dafür, dass alle folgenden Parameter ignoriert werden oder?

Wofür ist das echo gut?

Da ls ein blödes Beispiel war, weil es ja hier u.a. darum geht ein Programm, dass eigentlich root braucht ohne root auszuführen, nehme ich nun mkdir. Und zwar will ich im Rootverzeichnis / einen Ordner erstellen ohne sudo. Dazu habe ich nun

1
2
3

#!/bin/sh

echo $(mkdir /test)

geschrieben. Dann mit

1

sudo visudo 

sudoers um die Zeile

ich ALL = NOPASSWD: /tmp/skript.sh

erweitert und darauf gehofft, dass ich nun unter / das Verzeichnis test erstellen konnte. Ging aber nicht. Ich komm bei dem Thma einfach nicht weiter...

Hast du denn das Skript mit vorgesetztem sudo ausgeführt? Das brauchst du immernoch. Und du musst natürlich das Skript ausführen.

Wenn du Parameter (z.B. den Ordnernamen) übergeben willst musst du Variablen nutzen. Dies war im ls-Beispiel $*, wodurch alle Parameter weitergereicht werden. Falls du die Argumente noch auf Ihre Gültigkeit überprüfen musst wird dies alles natürlich komplizierter.

Den echo $(...) Konstrukt brauchst du nur, wenn das ausgeführte Kommando einen Text zurückliefert, den du auswerten möchtest.

Das -- sorgt dafür, dass alle folgenden Parameter ignoriert werden oder?

Ja. Danach durften in obigem Beispiel nurnoch Ordnernamen folgen.

Danke sehr. Ich hatte tatsächlich kein sudo vorgeschrieben, weil ich dachte, dass man es gar nicht mehr bräuchte. Damit bin ich nun einen großen Schritt weiter.

Ich weiß nicht ob es schon angesprochen wurde: Das Skript, welchem per sudoers Rootrechte eingeräumt werden, sollte nur von root geändert werden können. Das Skript sollte auch in einem komplett von root kontrollierten Pfad liegen. Sonst reißt man sich eine unnötige Lücke. Also:

Skript sollte nicht in /tmp, /home/user/..., sondern z.b. unter /usr/local/bin liegen. Dann:

sudo chown root.root /usr/local/bin/skript
sudo chmod 0755 /usr/local/bin/skript

Danke für den wichtigen Hinweis.

Sudoers hat bei mir irgendeinen Fehlerausgelöst. Ich habe ihn nicht genau analysiert, weil ich nun einen Workaround nutzte. Jedenfalls rufe ich ein Skript auf, welches per sudoers kein pw braucht. Dieses Skript ruft dann mount auf, welches eine USB HDD mountet, die per fstab ebenfalls ohne sudo aufgerufen werden kann. Genauer gesagt mit der Option "user". Jedoch bekam ich dann kein Schreibrecht mehr auf die HDD. Mounte ich die HDD ohne Skript, funktioniert es, wie es soll. Wisst ihr woran das liegt?

Jedenfalls nutze ich nun am Anfang des Skripts "read", speicher mein Pw in einer Variable und per Pipe leite ich es weiter an sudo. Aber irgendwie klingt das doch recht unsicher. Was sagt ihr?

MfG

Du rufst das Skript per sudo auf, ergo läuft es mit Rootrechten und somit führt auch root den mount-Befehl aus.

Wird das Skript tatsächlich per sudo aufgerufen wenn man es in sudoers einträgt? Denn ich habe es manuell ohne sudo aufgerufen und im Skript sudo nur an einer anderen Stelle genutzt.

Unix Samurai schrieb:

Wird das Skript tatsächlich per sudo aufgerufen wenn man es in sudoers einträgt? Denn ich habe es manuell ohne sudo aufgerufen und im Skript sudo nur an einer anderen Stelle genutzt.

Nur das, was explizit mit sudo gestartet wird, läuft auch mit sudo.

MoHo1 schrieb:

Den echo $(...) Konstrukt brauchst du nur, wenn das ausgeführte Kommando einen Text zurückliefert, den du auswerten möchtest.

Wirklich Sinn ergibt dieses Konstrukt für mich nicht. Die Klammerung $(<cmd>) fängt doch nur die Ausgabe von <cmd> ab und übergibt sie an echo welches diese wiederum ausgibt. D.h. echo $(<cmd>) gibt letztendlich nur die Ausgabe von <cmd> aus und ist damit äquivalent zur Ausgabe ohne diese Konstruktion!?

DrScott schrieb:

Ich weiß nicht ob es schon angesprochen wurde: Das Skript, welchem per sudoers Rootrechte eingeräumt werden, sollte nur von root geändert werden können. Das Skript sollte auch in einem komplett von root kontrollierten Pfad liegen. Sonst reißt man sich eine unnötige Lücke.

Das ist absolut wichtig, da ein vom User manipulierbares Skript, das in der /etc/sudoers eingetragen ist, genutzt werden kann, um jeden beliebigen Befehl mit root-Rechten auszuführen.

Allerdings musst du darüberhinaus auch darauf achten, dass auch alle im Skript verwendeten Befehle nicht vom User manipuliert werden können. Allein schon das kurze Skript

1
2
3
4

#!/bin/sh
# sicheres_skript.sh

ls -l -- "$@"

lässt sich ausnutzen, da der User den Pfad zum tatsächlich verwendeten ls über die Umgebungsvariablen manipulieren kann:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# eigene Version von ls anlegen
mkdir -p ~/bin/
cat > ~/bin/ls <<EOT
#!/bin/sh
echo "Tue böse Dinge hier"
EOT
chmod +x ~/bin/ls

# eigene Version zum Suchpfad hinzufügen
export PATH="/home/$USER/bin:$PATH"

# Skript aus sudoers ausführen und somit die eigene Version von ls
sudo sicheres_skript.sh

Für diese Lücke gibt es zwei Lösungsansätze:

1
2
3
4
5
6
7
8

#!/bin/sh
# sicheres_skript.sh

# 1. Umgebungsvariablen auf sichere Werte setzen
export PATH=/bin:/usr/bin:/sbin:/usr/sbin   # ggf. erweitern

# oder 2. absolute Pfade angeben
/bin/ls -l -- "$@"

Und wenn du weitere Argumente an das Skript übergeben willst, achte darauf, dass diese immer richtig in Anführungszeichen ("$@") stehen, damit es zu keinen Problemen mit z.B. Leerzeichen darin kommt.

Unix Samurai schrieb:

Sudoers hat bei mir irgendeinen Fehlerausgelöst. Ich habe ihn nicht genau analysiert, weil ich nun einen Workaround nutzte. Jedenfalls rufe ich ein Skript auf, welches per sudoers kein pw braucht. Dieses Skript ruft dann mount auf, welches eine USB HDD mountet, die per fstab ebenfalls ohne sudo aufgerufen werden kann. Genauer gesagt mit der Option "user".

Solange die root-Rechte nur für mount benötigt werden, solltest du hier soweit wie möglich den Weg ausschließlich wie hier über die fstab gehen.

Jedoch bekam ich dann kein Schreibrecht mehr auf die HDD. Mounte ich die HDD ohne Skript, funktioniert es, wie es soll. Wisst ihr woran das liegt?

Wie genau lautet die Zeile in der fstab und der mount-Befehl dazu und wie sind die Berechtigungen des Mountpoints vor und nach dem Mount?

Was hier vermutlich passiert, ist, dass der Mount erfolgreich ist, aber wegen der user-Option nur dem einhängenden User die Zugriffe gewährt werden. Bei der Verwendung von sudo ist der einhängende User aber root, wodurch anschließend nur root Zugriff hat.

Froggy