Am Freitag 28 April 2006 20:14 schrieb Sandro Frenzel:
Und was ist, wenn ich mir jetzt ein Programm aus dem Inet ziehe und
es bei einem ./configure irgendein Scheiß mit meinem Home-Verzeichnis
macht? Wie erkenne ich sowas? Vor sowas kann man sich doch gar nicht
schützen, oder?
Doch, indem Du
Am Donnerstag 27 April 2006 21:43 schrieb Thomas Kreft:
Jetzt bin ich neugierig: Was kann ein 'halt' bei einem Debian
kaputtmachen?
Die komplette ungesicherte Arbeit, den gerade laufenden Download, die
Arbeit anderer user auf dem gleichen Rechner (in ungünstigen
Szenarien - fehlerhafte
Matthias Haegele wrote:
Wie wäre es, wenn du jeweils vorher mit man in die Handbuchseite
guckst?
Zu lang (die Ausgabe), wenn dann --help als option.
Es gibt auch Kommandos (eher Scripte in verschiedensten Sprachen), die
keine Parameter auswerten, da macht es keinen Unterschied, ob Du
Jakob Lenfers schrieb:
Matthias Haegele wrote:
Wie wäre es, wenn du jeweils vorher mit man in die Handbuchseite
guckst?
Zu lang (die Ausgabe), wenn dann --help als option.
Es gibt auch Kommandos (eher Scripte in verschiedensten Sprachen), die
keine Parameter auswerten, da macht es keinen
Also sprach Jakob Lenfers [EMAIL PROTECTED] (Fri, 28 Apr
2006 14:59:22 +0200):
Matthias Haegele wrote:
Wie wäre es, wenn du jeweils vorher mit man in die Handbuchseite
guckst?
Zu lang (die Ausgabe), wenn dann --help als option.
Es gibt auch Kommandos (eher Scripte in verschiedensten
Am Freitag 28 April 2006 15:55 schrieb Christoph Haas:
On Thu, Apr 27, 2006 at 09:43:37PM +0200, Klaus Zerwes wrote:
Christoph Haas schrieb:
Ansonsten der Standard-Tipp: nimmt . nicht mit in den $PATH auf, damit
dir niemand was unterjubeln kann. Aber das meintest du sicher mit deinem
Sandro Frenzel schrieb:
Am Freitag 28 April 2006 15:55 schrieb Christoph Haas:
On Thu, Apr 27, 2006 at 09:43:37PM +0200, Klaus Zerwes wrote:
Christoph Haas schrieb:
Ansonsten der Standard-Tipp: nimmt . nicht mit in den $PATH auf, damit
dir niemand was unterjubeln kann. Aber das meintest du
Am Freitag 28 April 2006 17:15 schrieb Christoph Haas:
Mir ging es darum, nicht . mit in den $PATH aufzunehmen. Wenn du das
tust, werden Programme auch im aktuellen Verzeichnis gesucht. Siehe mein
ls-Beispiel. Es geht nicht darum, dass jemand in /usr/bin Unsinn macht.
Dafür braucht man
Sandro Frenzel wrote:
Und was ist, wenn ich mir jetzt ein Programm aus dem Inet ziehe
und es bei einem ./configure irgendein Scheiß mit meinem
Home-Verzeichnis macht? Wie erkenne ich sowas? Vor sowas kann man
sich doch gar nicht schützen, oder?
Doch, durch das ausschließliche Verwenden
Thorsten Haude schrieb:
Gibt es unix/linux-Kommandos die ernsthaft was kaputtmachen könnten wenn
sie ohne Argumente ausgeführt werden (ohne Berücksichtigung von
(untergeschobenen) Scripten 3.er natürlich ...)?
Je nach Plattform:
halt
killall
Jetzt bin ich neugierig: Was kann ein 'halt'
Christoph Haas schrieb:
On Thu, Apr 27, 2006 at 09:15:01PM +0200, Matthias Haegele wrote:
Habe mir angewöhnt unbekannte Kommandos einfach mal so auszuprobieren
(ohne Argumente) manchmal prüfe ich vorher noch mit whereis wo sie
herkommen (das mache ich natürlich nur auf meinem privaten
Christoph Haas schrieb:
On Thu, Apr 27, 2006 at 09:15:01PM +0200, Matthias Haegele wrote:
[...]
Ansonsten der Standard-Tipp: nimmt . nicht mit in den $PATH auf, damit
dir niemand was unterjubeln kann. Aber das meintest du sicher mit deinem
letzten Satz.
Hm - wenn ich befürchten muß das mir
Am Donnerstag, 27. April 2006 22:33 schrieb Wolf Wiegand:
Hallo,
Klaus Zerwes wrote:
Ansonsten der Standard-Tipp: nimmt . nicht mit in den $PATH
auf, damit
dir niemand was unterjubeln kann. Aber das meintest du sicher
mit deinem
letzten Satz.
Hm - wenn ich befürchten muß das mir
13 matches
Mail list logo
