mehrere Abfragen schöner und in weniger Zeilen schreiben

[pangu]

Hi Leute,

ich schreib grad ein Skript für Bacula, dass automatisch über bsmtp eine Nachricht an einem Empfänger sendet mit der Info, welches Band er einlegen muss. Ich hab eine Funktion verwendet die wie folgt aussieht:

Code: Alles auswählen

Bandabfrage() {
   mt -f /dev/st0 status | grep -q "DR_OPEN IM_REP_EN"
   if [ $? -eq 0 ]; then
    lwstatus=0
   fi
   mt -f /dev/st0 status | grep -q "BOT ONLINE IM_REP_EN"
   if [ $? -eq 0 ]; then
    lwstatus=1
   fi
   mt -f /dev/st0 status | grep -q "Device or resource busy"
   if [ $? -eq 0 ]; then
    lwstatus=2
   fi
 }

das ist jedoch nicht schön und ich mag so was nicht. Wie schreib ich das aber geschickt um? Der Befehl "mt -f /dev/st0 status" greift auf das Bandlaufwerk zu und liest den Status aus. Ich möchte dass nur 1x dieser Befehl ausgeführt wird, und je nach Fall die Variable lwstatus ihren Wert erhält, damit ich diesen weiterverwenden kann im Laufe des Skripts. Ich möchte also aus verschiedenen Stellen meines Skriptes diese Funktion aufrufen können, und anhand der Variable lwstatus weiß ich, ob das Laufwerk leer ist (lwstatus=0), ob ein Band im laufwerk eingelegt ist aber noch nicht gemountet wurde (lwstatus=1), oder ob ein Band im Laufwerk eingelegt ist und gemountet ist (lwstatus=2).

Würde man da irgendwie mit "case" arbeiten oder wie macht man das geschickt in möglichst wenig code? freue mich auf eure Hilfe und bedanke mich im Voraus.

[rendegast]

Code: Alles auswählen

TEMP=$(mktemp /tmp/mtstatus.XXXXXXX)
mt -f /dev/st0 status > $TEMP
......
......
rm $TEMP

EDIT -----------------------------------------------------

grep -q "DR_OPEN IM_REP_EN"
if [ $? -eq 0 ]; then
lwstatus=0
fi

->

Code: Alles auswählen

grep -q "DR_OPEN IM_REP_EN" $TEMP && lwstatus=0

[pangu]

ich kann dir nich ganz folgen. Damit erstelle ich eine Datei im /tmp Verzeichnis, aber was hab ich davon? bitte erklär mir das näher, da ich das wohl nicht genau verstanden habe was du meinst. Ich möchte ja eine Funktion in meinem Skript bauen, die ich dann später aus verschiedenen Stellen des skriptes heraus, aufrufen möchte. Und zwar immer dann, wenn ich den Status des Laufwerks ermitteln möchte.

[rendegast]

Du hast die (einmalig ermittelte) Ausgabe in einer Datei.
Damit zu arbeiten ist "billig" im Vergleich zu den Abfragen des Laufwerkes.
(Zumal /tmp/ mittlerweile oft ein tmpfs ist.)

Im obigen EDIT dann noch eine vereinfachte Variablen-Zuweisung.

Wird das in eine Funktion gepackt, so muß die Variable vielleicht noch exportiert werden.

Code: Alles auswählen

export lwstatus

[pangu]

Ah, du meinst also so?

Code: Alles auswählen

Bandabfrage() {
 TEMP=$(mktemp=/tmp/mtstatus.XXXXXXX)
 mt -f /dev/st0 status > $TEMP
grep -q "DR_OPEN IM_REP_EN" $TEMP && lwstatus=0
grep -q "BOT ONLINE IM_REP_EN" $TEMP && lwstatus=1
grep -q "Device or resource busy" $TEMP && lwstatus=2
rm $TEMP
}

[rendegast]

Yepp (mktemp ohne =, mein Fehler)

Als Test vielleicht

Code: Alles auswählen

Bandabfrage() {
 TEMP=$(mktemp /tmp/mtstatus.XXXXXXX)
 date > $TEMP
grep -q "2013" $TEMP && lwstatus="$(< $TEMP)"

rm $TEMP
}

Bandabfrage
echo "$lwstatus"
sleep 1
Bandabfrage
echo "$lwstatus"
sleep 1
Bandabfrage
echo "$lwstatus"

Und es sollten davon keine /tmp/mtstatus.* übrig bleiben

[pangu]

wollt grad fragen, aber du hast ja bereits korrigiert das = hatte Fehler produziert bei meinem Testskript. Also ich hab das jetzt so gemacht und funzt astrein. Ich musste lediglich noch eine Kleinigkeit anpassen, da die Ausgabe im Falle von "Device resouce is busy" auf die Ausgabe 2 erfolgt und somit nix im temp-file gelandet ist.

die Funktion sieht also so aus:

Code: Alles auswählen

Bandabfrage() {
 TEMP=$(mktemp /tmp/mtstatus.XXXXXXX)
 mt -f /dev/st0 status >$TEMP 2>&1
grep -q "DR_OPEN IM_REP_EN" $TEMP && lwstatus=0
grep -q "BOT ONLINE IM_REP_EN" $TEMP && lwstatus=1
grep -q "Device or resource busy" $TEMP && lwstatus=2
rm $TEMP
}

DANKE DIR !!!

[rendegast]

Was noch zu bedenken wäre, eine Anfangs- resp. Fehleraktion.
Es wäre ja denkbar das 'mt status' keine passende Ausgabe erzeugt.
An dem Punkt würde dann lwstatus aus der vorherigen Bandabfrage gelten.
In der Art

Code: Alles auswählen

Bandabfrage() {
 TEMP=$(mktemp /tmp/mtstatus.XXXXXXX)
 mt -f /dev/st0 status >$TEMP 2>&1
lwstatus=FAIL
grep -q "DR_OPEN IM_REP_EN" $TEMP && lwstatus=0
grep -q "BOT ONLINE IM_REP_EN" $TEMP && lwstatus=1
grep -q "Device or resource busy" $TEMP && lwstatus=2
rm $TEMP
}
.....
......
Bandabfrage
[ "xFAIL" = "x$lwstatus" ] && { echo "Undefinierter Bandstatus"; exit 1; }

[pangu]

DANKE!

[habakug]

Hallo!

Die Shell erzeugt und verwaltet ein Tempfile auch alleine, etwa so:

Code: Alles auswählen

Bandabfrage() {
 mt -f /dev/st0 status > temp.$$ 2>&1
lwstatus=FAIL
grep -q "DR_OPEN IM_REP_EN" temp.$$ && lwstatus=0
[...]
rm temp.$$
[...]

Gruß, habakug

[Cae]

Code: Alles auswählen

Bandabfrage() {
	lwstatus="$(mt -f /dev/st0 status 2>&1 | awk '
		/DR_OPEN IM_REP_EN/       { print 0; }
		/BOT ONLINE IM_REP_EN/    { print 1; }
		/Device or resource busy/ { print 2; }
	')";
 }

oder schoener:

Code: Alles auswählen

Bandabfrage() {
	mt -f /dev/st0 status 2>&1 | awk '
		/DR_OPEN IM_REP_EN/       { exit 0; }
		/BOT ONLINE IM_REP_EN/    { exit 1; }
		/Device or resource busy/ { exit 2; }
		{ exit 42; } # default
	';
	# *keine* weiteren Befehle, die den retcode verfaelschen
}

Bandabfrage;
case "$?" in
0)
	#...
	;;
1)
	#...
	;;
42)
	echo n.def. >&2;
	exit 42;
	;;
esac

Beachte, dass bei nicht gemachten Outputs im ersten Fall $lwstatus leer sein wird.

Gruss Cae

[goeb]

Hallo!

Die Shell erzeugt und verwaltet ein Tempfile auch alleine, etwa so:

Code: Alles auswählen

Bandabfrage() {
 mt -f /dev/st0 status > temp.$$ 2>&1
lwstatus=FAIL
grep -q "DR_OPEN IM_REP_EN" temp.$$ && lwstatus=0
[...]
rm temp.$$
[...]

Gruß, habakug

Dann schreib aber wenigstens noch dazu daß das in Verzeichnissen für die noch andere Personen Schreibrechte haben ne ganz dumme Idee ist.

[pangu]

Danke für den Hinweis, daß ich auch gleich /tmp/mtstatus_tmp.$$ nutzen kann
@GOEB: Was bedeutet das? Ist das ein Sicherheitsrisiko? Sollte ich das also lieber nich nutzen, und stattdessen die von rendegast empfohlene Variante bevorzugen?

Und danke auch an dich Cae, wieder was dazugelernt. Werd mir das für die Zukunft merken, und hoffentlich auch schaffen beim nächsten Mal das Snipplet selbst hinzubekommen

Grüße,
Pangu.

[goeb]

Danke für den Hinweis, daß ich auch gleich /tmp/mtstatus_tmp.$$ nutzen kann
@GOEB: Was bedeutet das? Ist das ein Sicherheitsrisiko? Sollte ich das also lieber nich nutzen, und stattdessen die von rendegast empfohlene Variante bevorzugen?

$$ ist nichts anderes als die PID der aktuellen Shell, die kann man relativ gut eingrenzen. Und gerade in /tmp willst du soetwas nicht benutzen. Es muß nur jemand einen symbolischen Link mit dem richtigen Namen in /tmp anlegen, und das Ziel des Links wird von deinem Skript überschrieben (solang derjenige der das Skript ausführt die notwendigen Rechte hat). mktemp existiert nicht ohne Grund, also nutze es auch.

[pangu]

dann werde ich mich mit mktemp anfreunden. Vielen Dank für diese ausführliche Erklärung und Warnung. DANKE !

[habakug]

Hallo!

@goeb
Ich würde mich freuen wenn du mal beschreibst, wie der Exploit (noch) funktionieren soll. Hier ist es zumindestens ohne Klimmzüge so:

Code: Alles auswählen

user2:~$ echo $$
4485
user1:~$ echo "geheim" > temp.4485
user1:~$ ln -s /home/user1/temp.4485 /tmp/temp.4485
user1:~$ cat temp.4485
geheim
user1:~$ cat /tmp/temp.4485 
geheim
user1:~$ ls -lisa /tmp/temp.4485 
28559 0 lrwxrwxrwx 1 user1 user1 22 Jul 31 18:47 /tmp/temp.4485 -> /home/user1/temp.4485
user2:~$ cat /tmp/temp.4485 
cat: /tmp/temp.4485: Keine Berechtigung
user2:~$ echo "oeffentlich" > temp.$$
user2:~$ cat temp.$$
oeffentlich
user2:~$ cat /tmp/temp.4485 
cat: /tmp/temp.4485: Keine Berechtigung
user2:~$ whereis temp.$$
temp:
user2:~$ whereis temp.4485
temp:
user1:~$ cat /tmp/temp.4485 
geheim
user1:~$ cat /home/user1/temp.4485 
geheim

Also "temp.$$" ungleich "/tmp/temp.{pidof_shell_user2}".

Gruß, habakug

[goeb]

Keine Ahnung was dein Beispiel soll, das dein user2 Dateien von user1 weder selbst lesen noch schreiben kann sollte klar sein.

Angenommen dein user1 hat eine Datei namens ~/datei. Dein user1 hat auch ein Skript das Daten in eine temporäre Datei /tmp/xyz schreibt. user2 legt jetzt den Link /tmp/xyz mit dem Ziel ~user1/datei an. Was passiert, wenn dein user1 jetzt das Skript aufruft und Daten in /tmp/xyz schreibt? Theoretisch (s.u.) wird das Ziel des Links überschrieben, also die ~/datei von user1. (Und das da jetzt nirgendwo $$ vorkommt spielt keine Rolle. Es geht ums Prinzip, und $$ ist eben etwas anderes als eine zufällige Zeichenkette. Und schlag jetzt bitte nicht vor das man ja vorher überprüfen kann ob der Link existiert oder nicht. Kann man, reicht im Zweifelsfall aber eben nicht aus.)

In der Praxis: Unter Linux ist das mittlerweile unproblematisch, solang für /tmp das Sticky-Bit gesetzt ist und der Kernel neu genug ist. Links in Sticky-Bit-Verzeichnissen funktionieren dann nur wenn der Besitzer des Links und der Besitzer des Ziels identisch sind IIRC. Das ist aber noch lang kein kein Grund so etwas potentiell Gefährliches zu machen.

[Cae]

Code: Alles auswählen

$ for i in $(seq "$((ps a | awk '{ print $1 }' | sort -rn | head -1 | tr -d '\n'; echo " * 2") | bc)"); do ln -nfs /etc/passwd "/tmp/temp.$i"; done
$ find /tmp -name 'temp*' 2>/dev/null | wc -l
56664
$ sh -c 'ls -ln /tmp/temp.$$'
lrwxrwxrwx 1 1000 1000 11 Jul 31 18:33 /tmp/temp.6932 -> /etc/passwd

Und falls root zu diesem Zeitpunkt nach /tmp/temp.$$ temporaere Daten schreibt, killt er stattdessen die /etc/passwd.

Diese Pipeline im Schleifenkopf soll ermitteln, was gerade die hoechste PID im System ist und den doppelten Wert als Maximum annehmen.

Gruss Cae

[goeb]

In der Praxis: Unter Linux ist das mittlerweile unproblematisch, solang für /tmp das Sticky-Bit gesetzt ist und der Kernel neu genug ist. Links in Sticky-Bit-Verzeichnissen funktionieren dann nur wenn der Besitzer des Links und der Besitzer des Ziels identisch sind IIRC. Das ist aber noch lang kein kein Grund so etwas potentiell Gefährliches zu machen.

Nochwas dazu: Hab grad mal danach gesucht und ausser einem LWN-Artikel nichts weiter dazu gefunden. Bei mir sieht es in Sticky-Verzeichnissen so aus (ohne gesetztes Sticky-Bit klappt es wie erwartet):

Code: Alles auswählen

~# echo test >testfile

~$ ln -s /root/testfile /tmp/testfile

~# cat /tmp/testfile
cat: /tmp/testfile: Keine Berechtigung

~# cat $( readlink /tmp/testfile )
test

Ob das jetzt im Vanilla-Kernel mit drin ist, oder ein Debian-Patch, keine Ahnung.

[linuxCowboy]

@goeb:
Danke für den Link!

Code: Alles auswählen

~# cat /tmp/testfile
cat: /tmp/testfile: Keine Berechtigung

Sollte root nicht immer Zugriff haben?!

@Cae:

Code: Alles auswählen

for i in $(seq "$((ps a | awk '{ print $1 }' | sort -rn | head -1 | tr -d '\n'; echo " * 2") | bc)"); do ln -nfs /etc/passwd "/tmp/temp.$i"; done

Originell! ...aber vielleicht sollte man einfach 60000 setzen?

[linuxCowboy]

...Links im /tmp-dir:

Wenn ein Link von root im /tmp existiert, kann ihn user nicht überschreiben:
Permission denied

Wenn root einen Link erstellen will, den user bereits erstellt hat, klappt das auch nicht:
File exists

Wenn root allerdings einfach ein File oder Link in einem sticky-dir verwendet kommt kein Fehler, egal wem das oder der gehört!

Also, und damit schließt sich der Kreis, mktemp verwenden!

(So stellt sich mir die Sache jedenfalls dar.)

[goeb]

Code: Alles auswählen

~# cat /tmp/testfile
cat: /tmp/testfile: Keine Berechtigung

Sollte root nicht immer Zugriff haben?!

In dem Fall eben nicht, sonst wäre die Änderung sinnlos. Nochmal: das gilt nur wenn für das Verzeichnis das Sticky-Bit gesetzt ist und Link-Owner und Ziel-Owner nicht übereinstimmen. Und das muß wie gesagt nicht für alle Systeme gelten, unter Wheezy ist es aber so.

...Links im /tmp-dir:

Wenn ein Link von root im /tmp existiert, kann ihn user nicht überschreiben:
Permission denied

Was meinst du jetzt mit überschreiben? Den Inhalt des Ziels ändern oder den Link ändern? Daß der Benutzer den Link nicht ändern oder löschen kann ist klar, wegen Sticky-Bit. Und für den Inhalt der Zieldatei gilt: wenn der Benutzer dafür keine Schreibrechte hat kann er ihn sowieso nicht ändern, egal wem der Link gehört. Wenn der Benutzer Schreibrechte hätte, aber der Link einem anderen Benutzer gehört als die Zieldatei wird (zumindest unter Wheezy) trotzdem die Berechtigung verweigert (wegen Sticky-Bit, unabhängig von den eigentlichen Schreibrechten im Dateisystem).

Wenn root einen Link erstellen will, den user bereits erstellt hat, klappt das auch nicht:
File exists

Darum gehts aber nicht.

Und wenn root anlass- und prüfungslos einen Link in einem sticky-dir nutzt, den er nicht selbst erstellt hat...
... wird er sicher nicht 'Admin des Jahres' :lol:

War mein Beispiel oben so schwer zu verstehen? root (oder im Beispiel user1) will keinen Link benutzen, er will irgendetwas in eine normale Datei schreiben (echo 'something' >$tmpfile). Und selbst wenn du vorher prüfst ob die Datei (oder ein Link mit dem Namen) nicht existiert hast du noch eine Race Condition weil der Angreifer zwischen Test und Schreibvorgang den Link anlegen kann.

[linuxCowboy]

Code: Alles auswählen

~# cat /tmp/testfile
cat: /tmp/testfile: Keine Berechtigung

Sollte root nicht immer Zugriff haben?!

In dem Fall eben nicht, sonst wäre die Änderung sinnlos. Nochmal: das gilt nur wenn für das Verzeichnis das Sticky-Bit gesetzt ist und Link-Owner und Ziel-Owner nicht übereinstimmen. Und das muß wie gesagt nicht für alle Systeme gelten, unter Wheezy ist es aber so.

Na das ist ja ein toller Trick! Unter Squeeze ist es nicht so. Und bei der LPI-Prüfung brauch man mit sowas auch nicht kommen (denke ich!)

Der Sache sollte man weiter auf den Grund gehen...

(ich kann mir etwas auf meinem System nicht anschauen... )

Was meinst du jetzt mit überschreiben? Den Inhalt des Ziels ändern oder den Link ändern?

Wenn root einen eigenen Link im /tmp erstellen will. Gibts den schon, kommt ein Fehler.
Ansonsten hat root überall Zugriff. Ihn stört auch kein sticky-bit.
Und eben darum, wenn ich nur schreibe, als root, schreibe ich wohin der Link zeigt. Ohne Fehler!

Und für den Inhalt der Zieldatei gilt: wenn der Benutzer dafür keine Schreibrechte hat kann er ihn sowieso nicht ändern, egal wem der Link gehört.

Das gilt eben nicht für root! s.o.

War mein Beispiel oben so schwer zu verstehen? root (oder im Beispiel user1) will keinen Link benutzen, er will irgendetwas in eine normale Datei schreiben (echo 'something' >$tmpfile). Und selbst wenn du vorher prüfst ob die Datei (oder ein Link mit dem Namen) nicht existiert hast du noch eine Race Condition weil der Angreifer zwischen Test und Schreibvorgang den Link anlegen kann.

Richtig. Ich hatte mir den Thread nochmal angesehen und nachgedacht, und dann meinen Post geändert.

Allerdings das mit dem TOCTTOU-Angriff (time-of-check-to-time-of-use) halte ich für eher theoretisch. Cae erstellt seine tausenden temp.??-Files irgendwann vorher!

[goeb]

Wenn root einen eigenen Link im /tmp erstellen will. Gibts den schon, kommt ein Fehler.

Stimmt. Keine Ahnung woran das liegt. root kann in dem Fall aber den Link manuell löschen, nur ln -f funktioniert nicht.

Und für den Inhalt der Zieldatei gilt: wenn der Benutzer dafür keine Schreibrechte hat kann er ihn sowieso nicht ändern, egal wem der Link gehört.

Das gilt eben nicht für root! s.o.

Im Allgemeinen gilt das nicht für root, richtig. Nur in der erwähnten Konstellation kann eben auch root nicht auf den Link zugreifen.

Allerdings das mit dem TOCTTOU-Angriff (time-of-check-to-time-of-use) halte ich für eher theoretisch. Cae erstellt seine tausenden temp.??-Files irgendwann vorher!

Viel theoretischer als andere Sicherheitslücken die fleißig ausgenutzt werden ist es auch nicht. Und wenn man auf dem System noch ordentlich (I/O-)Last erzeugt sollte man Zeit zwischen Test und Schreiben durchaus soweit strecken können das es praktikabel wird. Und ohne Prüfung sind die vorher erzeugten Dateien natürlich auch gefährlich. Wer weiss schon was aus dem auf die Schnelle dahingetippten Shellskript, das wunderbar ohne Prüfung ausgekommen ist, mal wird. Und deswegen war der Tipp, $$ für temporäre Dateinamen zu verwenden, auch kein guter.

[linuxCowboy]

Wenn root einen eigenen Link im /tmp erstellen will. Gibts den schon, kommt ein Fehler.

Stimmt. Keine Ahnung woran das liegt. root kann in dem Fall aber den Link manuell löschen, nur ln -f funktioniert nicht.

Gute Idee. ln -f hatte ich vorhin gar nicht versucht. Unter squeeze klappt das! (als root)

also:

Code: Alles auswählen

~# ln -s /root/testfile /tmp/testfile 
ln: creating symbolic link `/tmp/testfile': File exists
~# ln -sf /root/testfile /tmp/testfile
~# ls -l /tmp/testfile
lrwxrwxrwx 1 root root 14 01.08. 2013 02:37:00 /tmp/testfile -> /root/testfile
~# uname -a
Linux P5 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux