Squid: rcsquid in Skript ausführen

[thomas2879]

Hallo,

auf meinem Erst-PC habe ich SuSE 9.0 installiert. Ich gehe dort über T-DSL ins Internet. Ich habe Squid 2.5 installiert, das beim Systemhochlauf gestartet wird. Meinen Zweit-PC habe ich mit meinem Erst-PC vernetzt. Wenn ich von meinem Zweit-PC aus ins Internet gehen will, wird keine Seite aufgerufen. Das Problem liegt daran, dass Squid beim Start die Voreinstellung für den DNS-Server einliest und bei der Einwahl ins Internet die aktuell zugewiesene DNS-Adresse nicht übernimmt. Wenn ich nach der Einwahl die DNS-Adresse über den Befehl 'rcsquid reload' aktualisiere, dann kann ich von meinem Zweit-PC ohne Probleme auf die Internet-Seiten zugreifen. Der rcsquid-Befehl kann allerdings nur unter root oder im su-Modus ausgeführt werden.

Ich möchte nun ein Skript haben, das vom kinternet automatisch bei der Einwahl aufgerufen wird und den rcsquid-Befehl ausführt. Ich habe mir ein solches Skript geschrieben und unter root funktioniert es tadellos.

Unter meiner eigenen Kennung gibt es mit dem Skript folgendes Problem:
- Wenn nur rcsquid enthalten ist, dann kommt die Fehlermeldung "command not found".
- Wenn ich vorher den Befehl su einfüge, dann wird bei Ablauf des Skriptes in den Superuser-Modus gewechselt, der rcsquid-Befehl aber nicht ausgeführt.

Wie muss ich das Skript schreiben, dass es unter einer beliebigen Kennung den rcsquid-Befehl ausführt? Noch etwas: Ich habe die Skript-Datei mit 'chmod +x <dateiname>' ausführbar gemacht. Muss ich hier eventuell was ändern?

Danke für Eure Hilfe!
Thomas

[ratte]

mir entgeht im Moment, warum der Squid neu gestartet werden muss, aber egal, was du in deiner jetzigen Situation im Script brauchst, ist wohl ein suid-Bit fuer rcsquid, dass du mittels `chmod +s` erreichen kannst. Damit koennen User das script aufrufen und es wird mit root Rechten ausgefuehrt. Ausfuehrbar war es vorher bestimmt auch schon, da es scih wohl um ein init-script handelt, oder nicht?

auf der anderen Seite meine ich mich erinnern zu koennen, dass dies ein altes Problem ist und schon diskutiert wurde. Einfach mal suchen...

Wenn das nicht reicht, nochmal posten.

[Michael]

Trag doch einfach den DNS Deines Providers statisch
mit in die /etc/resolv.conf mit ein.

Cheers

Michael

[Michael]

Und starte squid mit -D, damit keine Einwahl forciert wird:

<blockquote><pre><font size="1" face="">code:</font><hr><font face="Courier New" size="2"> -D Disable initial DNS tests.</font><hr></pre></blockquote>

Cheers

Michael

[thomas2879]

Danke für Eure Antworten. Leider konnte ich aber das Problem noch nicht lösen.

@ratte:
Die verschiedenen Threads zum Thema squid habe ich durchgelesen und die Tips, die für meinen Fall passen könnten, ausprobiert, aber leider ohne Erfolg. Bei dem Skript habe ich heute das mit dem 'chmod +s' ausprobiert, aber leider hat sich bei meiner normalen User-Kennung dadurch nichts geändert. Das heisst, die Überführung in den su-Modus ist nicht erfolgt.

@Michael:
Bei t-online kann man sich wohl auf die Adresse des DNS-Servers nicht so verlassen, so dass empfohlen wird, sie sich dynamisch bei der Einwahl zuordnen zu lassen.

Jetzt bin ich also immer noch auf der Suche nach einer Möglichkeit, das 'rcsquid reload' unter meiner normalen User-Kennung per Skript auszuführen. Gibt es da noch eine Möglichkeit, per Freischaltung den Ablauf im su-Modus zu erreichen. Oder gibt es eine Syntax, mit der ich im Skript zuerst 'su' und dann 'rcsquid reload' ausführen kann. Ich habe den Eindruck, dass im letzteren Fall nach Ausführen von su der Interpreter in einem Modus ist, in dem er den rcsquid-Befehl nicht mehr erkennt.

Nochmal vielen Dank!
Thomas

[ratte]

manchmal dauert es ja etwas, bis man alle Sinne zusammen hat...

Also, das setuid Bit sorgt dafuer, dass eine ausfuehrbare Datei mit den Rechten des Besitzers ausgefuehrt wird. Wenn man ein Script oder ein Binary mit setuid Bit versieht, laeuft das Script oder das Binary mit den Rechten des Eigentuemers, gehoert die Datei root, also mit root Rechten. Allerdings kommt zum Script eine Besonderheit dazu, naemlich dass eine neue Shell aufgemacht wird, diese allerdings mit den Rechten des Ausfuehrenden. Darin gibt es den setuid Kontext _nicht_ mehr. Binaries laufen i.d.R. in der Shell des Aufrufenden, deshalb gilt dort dann der setuid Kontext.
Darum kann ein Script, selbst wenn es setuid gesetzt ist, von Usern nicht verwendet werden, wenn es Programme aufruft, die wiederrum root Rechte erfordern.
Das kann man leicht selbst testen. Also root platziert man eine Datei meintest.sh in das Home des Users mit der Zeile

ls /root

Anschliessend macht man als root diese Datei ausfuehrbar und setzt das setuid Bit. Wenn man als User diese Datei ausfuehrt, passiert folgendes:

$ ./meintest.sh
ls: /root: Permission denied

Allerdings ist eventuell ein Binary, dass im Script aufgerufen wird, einfach nur nicht im Pfad eines Users. Das ist z.B. bei ifconfig so.

which ifconfig

funktioniert nur bei root und nicht bei Usern, allerdings koennen User unter Angabe des absoluten Pfades ifconfig unter User Rechten anfuehren. Und nun sind wir bei dem Problem von squid angekommen. squid wieauch ifconfig sind Programme, die Dienste des Servers steuern. Da Linux ein Multiuser System ist, darf nicht jeder alles, vor allem darf nicht jeder User an den Diensten rumschrauben - damit die von root eingerichteten Dienste sicher laufen. Z.B. kann man als User `/sbin/ifconfig eth0` ausfuehren, um sich die Konfiguration anzeigen zu lassen, `/sbin/ifconfig eth0 192.168.0.1` darf ein User aber nicht und fuehrt zum Abbruch mit Fehlermeldung.

Damit sind wir bei dem Punkt Sicherheit angelangt. Das Programm sudo erlaubt es, Programme, die nicht setuid gesetzt sind, als root auszufuehren. Damit die Sicherheit gewaehrleistet ist, ist sudo interaktiv und erfordert die Passwortangabe des Users. Wegen der Sicherheit laesst sich die Interaktivitaet nicht ausschalten, also erfordert sudo in Scripten immernoch die interaktive Eingabe des Passwortes, eine volle Automatisierung laesst sich mit sudo also nicht realisieren.

Was du machen koenntest, waere, deinem User root Rechte zu verleihen, aber damit waehre dein User root gleich, und das ist wohl nicht, was du willst, sonst koenntest du gleich als root surfen.

IMHO bleibt dir also nichts anderes uebrig, als nach erfolgreicher Einwahl in einer Shell durch `su -` root zu werden und dann das squid Startscript zu restarten.

ratte

[Jochen]

@ratte: Close, but no cigar! <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">

Skripte (zumindest Shellskripte) verweigern das SUID-Recht. Ein SUID-Shellskript so sicher zu machen, dass ein böswilliger Nutzer nicht die Ausführung beliebiger Kommandos erzwingen kann, ist dermassen schwer und hat schon in der Frühzeit von UNIX für so viel Sicherheitslücken gesorgt, dass so gut wie alle Shells ein SUID-Recht nicht verwenden bzw. es sofort fallen lassen. Der Weg ist also so oder so versperrt. Allerdings wäre ein Minimal-Wrapper in C sehr schnell geschrieben (und genauso unsicher).

sudo lässt ohne weiteres ein vollständige Automatisierung (und damit auch Verwendung in Skripten) zu. Die Abfrage eines Passwortes lässt sich in der /etc/sudoers über das NOPASSWD-Flag errreichen, siehe "man sudoers".

Jochen

[ratte]

Hi Jochen,

danke again fuer das Nachhilfeprogramm!

Gruss,

ratte

[thomas2879]

Hallo,

nochmal vielen Dank für Eure Hinweise! In der Zwischenzeit hat mir schon so etwas geschwant, dass man bestimmte Dinge von einer normalen User-Kennung aus nicht hinkriegt. Aber man muss sich erst verinnerlichen, was der Unterschied zwischen einem Single-Session und einem Multi-Session Betriebssystem ist. Und ein Linux-System ist wohl so quasi mit einem Großrechner vergleichbar, auch wenn man es nur ganz alleine nutzt.

Zu meinem eigentlichen Problem habe ich jetzt mit Hilfe des Administrations-Handbuchs eine ganz andere Lösung gefunden. Ich setzte jetzt zum squid zusätzlich noch den bind-9 ein. Als DNS Adresse habe ich nun 127.0.0.1 fest eingestellt. Jetzt habe ich also einen lokalen DNS, der als Brückenkopf zwischen dem squid und dem Provider DNS mit seiner dynamischen Adresse fungiert. Und so funktioniert es jetzt auch.

Viele Grüße,
Thomas