Hallo, kann mir mal jemand erklären, warum sich unter Linux Programme manchmal nur mit vorangestelltem ./ aufrufen lassen?
weil sie in einem höher angeordneten Verzeichnis liegen?
STK500-Besitzer schrieb: > weil sie in einem höher angeordneten Verzeichnis liegen? eher, weil sie im selben Verzeichnis liegen. Wenn nur der Programmname angegeben wird, wird in den in PATH angegebenen Pfaden danach gesucht. Die andere Möglichkeit ist, den Pfad explizit anzugeben, dabei ist . das aktuelle Verzeichnis. ../Programm würde beispielsweise etwas im übergeordneten Verzeichnis aufrufen. /bin/Programm absolut vom Wurzelverzeichnis aus usw...
Weil . aus Sicherheitsgründen zuweilen nicht im PATH ist.
genuer: bei linux wird nur der pfad ($PATH) nach dem programmnamen durchsucht. wenn dein programm irgendwo in deinem home-verzeichnis liegt wird es, selbst wenn du im CLI im selben verzeichnis stehst nicht gefunden wenn du nicht den vollen (oder relativen) pfad angibst.
Udo Schmitt schrieb: > Fred schrieb: >> aus Sicherheitsgründen > > Warum aus Sicherheitsgründen? > Die Frage ist ernst gemeint. weil man so verhindert einem nutzer z.b. ein falsches "ls" unterzujubeln. laut $PATH wird bei "ls -la" zuerst bin durchsucht, und nicht das verzeichnis in dem du grade stehst, z.b. ~/ .
Udo Schmitt schrieb: > Warum aus Sicherheitsgründen? Weil ich dir ein Programm mit dem Namen eines bash-builtins oder eines beliebigen anderen Programms, das du üblicherweise so aufrufst, in eins deiner Verzeichnisse (vermutlich ~) legen kann. Und wenn du dann versuchst, das "eigentlich gemeinte" Programm aufzurufen, führst du meins aus. Mit deinen Rechten!
Fred schrieb: > Weil ich dir ein Programm mit dem Namen eines bash-builtins oder eines > beliebigen anderen Programms, das du üblicherweise so aufrufst, in eins > deiner Verzeichnisse (vermutlich ~) legen kann. In eins seiner Verzeichnisse kommt man als Fremder normalerweise nicht rein. Aber man könnte beispielsweise eins nach /tmp legen:
1 | cd /tmp |
2 | echo ':' > ls |
3 | echo 'rm -rf $HOME' >> ls |
4 | chmod +x ls |
und dann hoffen, dass der Nutzer irgendwann mal folgendes macht:
1 | cd /tmp |
2 | ls |
Indem man sich angewöhnt, "." niemals in den PATH aufzunehmen, sondern stets ./ zu schreiben, wenn man etwas bewusst aus dem aktuellen Verzeichnis ausführen möchte, umgeht man dieses Risiko.
:
Bearbeitet durch Moderator
Jörg Wunsch schrieb: > Fred schrieb: >> Weil ich dir ein Programm mit dem Namen eines bash-builtins oder eines >> beliebigen anderen Programms, das du üblicherweise so aufrufst, in eins >> deiner Verzeichnisse (vermutlich ~) legen kann. > > In eins seiner Verzeichnisse kommt man als Fremder normalerweise > nicht rein. Da reicht's ja schon aus, wenn ich dir ein tar.gz schicke, du das bei dir entpackst und danach in dem Verzeichnis ein ls machst. > Indem man sich angewöhnt, "." niemals in den PATH aufzunehmen, sondern > stets ./ zu schreiben, wenn man etwas bewusst aus dem aktuellen > Verzeichnis ausführen möchte, umgeht man dieses Risiko. Es gilt halt unter Linux auch nicht als der Regelfall, daß man ein Programm im aktuellen Verzeichnis aufruft. Wenn ich mir z.B. ein Programm selbst compiliere und es dann vor der Installation schon im Build-Verzeichnis testhalber starten will, ist das eben sein Spezialfall.
Man kann "." schon in die PATH-Variable mit aufnehmen, sollte aber darauf achten, dass es an letzter Stelle (oder zumindest nach allen Systemverzeichnissen) steht. Natürlich könnte dann ein Bösewicht ähnlich Jörgs Vorschlag im /tmp-Verzeichnis zwei böse Programme namens "lls" und "lss" ablegen und hoffen, dass der Nutzer folgendes eintippt
1 | cd /tmp |
2 | ls |
und dabei die "l"- oder die "s"-Taste prellt. Ich persönlich kann mit diesem Risiko aber leben ;-)
Yalu X. schrieb: > Man kann "." schon in die PATH-Variable mit aufnehmen, sollte aber > darauf achten, dass es an letzter Stelle (oder zumindest nach allen > Systemverzeichnissen) steht. Wie soll das funktionieren, ohne in kürzester Zeit auf seltsame Ereignisse aufgrund gleichnamiger Dateien zu stoßen? Z.B. Skripte ala configure.sh finden sich mehrere Dutzend. Macht doch schon daher keiner, es wurde wohl ein Beispiel gebraucht ...
19:25 schrieb: > Z.B. Skripte ala configure.sh finden sich mehrere Dutzend. Allerdings (normalerweise) nicht innerhalb von PATH.
Prinzipiell liese sich das ganze dann auch zur Rechteausweitung anwenden, indem man z.B. eine Anwendung namens "apt-get" in ~/ ablegt. Beim nächsten "sudo apt-get install xyz" gibts dann ne böse Überraschung.
Das ist eine Eigenart von Linux, welches wirklich nur die, in der Path-Variablen, stehenden Verzeichnisse nach einem Befehl durchsucht. Interessanterweise schaut es auch nicht im aktuellen Verzeichnis nach. Genau wie bei DOS ist das "Punkt"-Verzeichnis das aktuelle. Der einzige Unterschied ist die Linuxer stehen auf den Schrägstrich (/) und in der Dose ist ein Backslash (\). Also im übertragenen Sinne haben "./" und ".\" die gleiche Bedeutung.
Yalu X. schrieb: > Man kann "." schon in die PATH-Variable mit aufnehmen, sollte aber > darauf achten, dass es an letzter Stelle (oder zumindest nach allen > Systemverzeichnissen) steht. Dann startet man allerdings versehentlich das falsche Programm, wenn es irgendwo im PATH schon eins mit dem gleichen Namen gibt. Der Klassiker ist da die Verwirrung, wenn jemand sich z.B. ein kleines C-Programm bastelt und es erstmal test nennt und sich dann wundert, warum sein printf ignoriert wird.
Jörg Wunsch schrieb: > Allerdings (normalerweise) nicht innerhalb von PATH. War eh ein bloedes Beispiel. ... und oups, was man nicht so alles in seiner /etc/profile findet, if [ ! "`id -u`" = "0" ]; then PATH="$PATH:." fi "Nicht-Roots" bekommen beim Shell-Aufruf, hier bash (/etc/profile -> ~/.bashrc), das aktuelle Verzeichnis in den Pfad gehaengt. Aber ist das notwendig?
vn nn schrieb: > Prinzipiell liese sich das ganze dann auch zur Rechteausweitung > anwenden, indem man z.B. eine Anwendung namens "apt-get" in ~/ ablegt. Wenn ein Bösewicht Schreibrechte auf mein Home-Verzeichnis hat, ändert er meine PATH-Variable durch Ändern von .bashrc sowieso nach seinem Belieben. Oder er ruft seine Malware gleich von meinem .bash_profile aus auf. In diesem Fall hat man ohnehin verloren. Rolf Magnus schrieb: > Dann startet man allerdings versehentlich das falsche Programm, wenn es > irgendwo im PATH schon eins mit dem gleichen Namen gibt. Der Klassiker > ist da die Verwirrung, wenn jemand sich z.B. ein kleines C-Programm > bastelt und es erstmal test nennt und sich dann wundert, warum sein > printf ignoriert wird. Die Verwirrung entsteht aber auch dann, wenn "." nicht in PATH enthalten ist, der potentiell Verwirrt-Werdende aber vergisst, dem "test" das "./" voranzustellen. Bei "test" passiert meist zum Glück nicht Schlimmes. Und dass man seine eigenen Programme nicht "rm" o.ä. nennt, das lehrt die Erfahrung ;-)
> ist, der potentiell Verwirrt-Werdende aber vergisst, dem "test" das "./" > voranzustellen. > > Bei "test" passiert meist zum Glück nicht Schlimmes. Und dass man seine > eigenen Programme nicht "rm" o.ä. nennt, das lehrt die Erfahrung ;-) So jetzt allen nochmal ein herzliches RTFM ;) man bash . filename [arguments] source filename [arguments] Read and execute commands from filename in the current shell environment and return the exit status of the last command exe- cuted from filename. If filename does not contain a slash, filenames in PATH are used to find the directory containing filname. The file searched for in PATH need not be executable. When bash is not in posix mode, the current directory is searched if no file is found in PATH. If the sourcepath option to the shopt builtin command is turned off, the PATH is not searched. If any arguments are supplied, they become the positional parameters when filename is executed. Otherwise the positional parameters are unchanged. The return status is the status of the last command exited within the script (0 if no commands are executed), , and false if filename is not found or cannot be read. This builtin is equivalent to source.
19:25 schrieb: >> ist, der potentiell Verwirrt-Werdende aber vergisst, ... Toller Satz, > So jetzt allen nochmal ein herzliches RTFM ;) shortcut, for full viewer convenience $ man bash|less -p '. filename \[arguments\]'
19:25 schrieb: > So jetzt allen nochmal ein herzliches RTFM ;) > > man bash > > . filename [arguments] > source filename [arguments] Dann lies das fcking manual richtig! . bla ist etwas völlig anderes als ./bla So, und nun darfst du dich wieder verkriechen. Meine Güte! Hauptsache, einen auf Checker machen.
Mit etwas gutem willen kriegst du das bestimmt noch unfreundlicher hin. Nein ist nicht das selbe, aber nicht alles was ausgefuehrt werden kann muss auch nicht unbedingt als ausfuehrbar gekennzeichnet sein. $ mkdir spielwiese $ cd spielwiese $ echo 'echo "Hello World!"' > hello $ ls -n total 4 -rw-r--r-- 1 1001 1001 20 2014-02-26 11:50 hello $ ./hello bash: ./hello: Permission denied $ hello bash: hello: command not found $ . hello Hello World! ---------------- $ chmod u+x hello $ ./hello Hello World! $ hello bash: hello: command not found $ pwd /tmp/spielwiese $ PATH="$PATH:/tmp/spielwiese" $ hello Hello World!
11:55 schrieb: > Mit etwas gutem willen kriegst du das bestimmt noch unfreundlicher hin. Da muß man sich ja nicht wundern, wenn man großkotzig mit "RTFM" auftritt und dann das Thema verfehlt. > Nein ist nicht das selbe Ist was vollkommen anderes... Beim ./ geht's darum, explizit das Verzeichnis anzugeben, wo das Programm liegt, das ausgeführt werden soll. Das einfache . ist das gleiche wie das Kommando 'source' und dient dazu, ein Skript statt in einer neuen Shell-Instanz in der aktuellen auszuführen. 11:55 schrieb: > $ . hello > Hello World! Das geht aber auch nur bei Skripten.
Yalu X. schrieb: > Wenn ein Bösewicht Schreibrechte auf mein Home-Verzeichnis hat, ändert > er meine PATH-Variable durch Ändern von .bashrc sowieso nach seinem > Belieben. Oder er ruft seine Malware gleich von meinem .bash_profile aus > auf. In diesem Fall hat man ohnehin verloren. Braucht er ja nicht mal, wie oben bereits geschrieben reicht es ja schon, sein Programm in ein Archiv zu packen, welches du entpackst.
Ach Leute, ich verirre mich ja wirklich selten in diese Gefilde hier - aber eure Diskussion hat mir mal wieder drastisch vor Augen geführt, warum ich Linux und alle unixoide BS nicht leiden mag. Mit größerem Abstand gesehen ist es wohl doch ein General-Bug, unixoide Shells überhaupt in einem Rechnersystem zu haben. Jetzt verweist bitte nicht auf abgesetzte Systeme und deren Fernwartung, ein PC ist nicht sowas und abgesetzte systeme sollten eine Firmware intus haben. FIRM eben. Manchmal kommt mir so ein abenteuerlicher Traum, bei derartigen OS einfach sämtliche Shells ersatzlos zu entfernen, dazu gleich auch noch sämtliche Shell-Skripte. Als nächstes auch noch führende Punkte bei Dateinamen verbieten und für ausführbare Dateien zwingend eine entsprechende Extension vorzuschreiben, die Ausführung von Dateien auf das aktuelle Verzeichnis zu beschränken mit Ausnahme von Anwendungen, die vom BS als namentlich bekannte und system-modale Anwendungen dediziert geführt werden oder per qualifizierter Pfadangabe. Als nächstes dann ersatzloses Entfallen jeglicher "home" Verzeichnisse und deren Ersatz durch Installationsverzeichnisse der Anwendungen innerhalb der Volumes sowie Einführen eines generellen Verzeichnisses "linux", wo ALLES, was sich bisher sonstwo im root Verzeichnis tummelt, hinverschoben ist, nur Verzeichnisse aber keinerlei Datei in root möglich, kurzum freiräumen von root, bis es etwa so aussieht wie bei Windows CE: nix außer temp, windows und benannte Volumes (soviel wie physisch vorhanden). ... ok, für begeisterte Linuxer dürfte das eher ein Alptraum sein, zwingt es sie doch zu einem Arbeiten mit Applikationen anstelle von Tools ;-) n schönen Abend noch, W.S.
W.S. schrieb: > ich verirre mich ja wirklich selten in diese Gefilde hier Ah, dein Beitrag hatte uns noch gefehlt. Danke dafür, wir hatten das schon vermisst!
W.S. schrieb: > ich verirre mich ja wirklich selten in diese Gefilde hier - aber eure > Diskussion hat mir mal wieder drastisch vor Augen geführt, warum ich > Linux und alle unixoide BS nicht leiden mag. Mit größerem Abstand > gesehen ist es wohl doch ein General-Bug, unixoide Shells überhaupt in > einem Rechnersystem zu haben. Und jetzt erklärst du uns bitte noch, wo da der Unterschied zu Windows besteht. Ach, warte, einen Unterschied gibt es, im Gegensatz zu unixartigen Systemen, wo durch den im Thread angeführten Mechanismus dieses Einfallstor geschlossen wurde, existiert es unter Windows weiterhin.
1 | >dir |
2 | <DIR> folder |
3 | song.mp3 |
4 | pic.jpg |
5 | xcopy.rar |
6 | |
7 | >xcopy pic.jpg folder |
8 | C:pic.jpg |
9 | 1 Datei(en) kopiert |
10 | |
11 | >rar -x xcopy.rar |
12 | |
13 | >dir |
14 | <DIR> folder |
15 | song.mp3 |
16 | pic.jpg |
17 | xcopy.exe |
18 | xcopy.rar |
19 | |
20 | >xcopy pic.jpg folder |
21 | gotcha! |
W.S. schrieb: > ich verirre mich ja wirklich selten in diese Gefilde hier - aber eure > Diskussion hat mir mal wieder drastisch vor Augen geführt, warum ich > Linux und alle unixoide BS nicht leiden mag. Mit größerem Abstand > gesehen ist es wohl doch ein General-Bug, unixoide Shells überhaupt in > einem Rechnersystem zu haben. Sowas kann nur jemand sagen, der nicht im geringsten weiß wovon er da redet.
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.