nicht angemeldet
Zugangsdaten [...] vielleicht nur ein Alias?
So wird's wohl sein.
drwx--x--x 0 0 /
»» Die anderen sind in Ordnung. Alle sind für den Benutzer lesbar. (Das ist der zweite Buchstabe, also »r« ist immer vorhanden statt »-«.)
--- dann wäre das Wurzelverzeichnis ja auch lesbar?
Nein, denn hier verhält es sich anders, weil das Verzeichnis dem Benutzer root (= nummerische Id 0) gehört. Ausschlaggebend ist daher nicht das erste »r«, sondern das dritte. Ich erörtere das nicht im Detail, um Berechtigungen zu verstehen, lies Kapitel 9 von der Linuxfibel. http://www.fibel.org/linux/lfo-0.6.0/node223.html
Serverarchitektur
Ist das falsche Wort, aber das, was du meinst, ist erklärt in http://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard.
Meinem rudimentären Verständnis nach gibt es ein "Wurzelverzeichnis" [...] Dann gibt es wohl mehrere Unterverzeichnisse und in einem dieser Unterverzeichnisse wohnen alle Kundensites, die auf dem Server untergebracht sind.
So kommt es mir nicht vor. Ich denke, dass im Wurzelverzeichnis schon die einzelnen Kundenverzeichnisse sind, in deinem Fall /vivnemhc.
»» Bleibt für mich abzuwarten, wie es sich mit dem Verzeichnis »/« verhält. Sollte dort die Leseberechtigung fehlen:
Ich stelle fest: es ist so.
»» da dieses Verzeichnis dem speziellen Benutzer »root« gehört, und du natürlich nicht dessen Fähigkeit hast, kannst du dort keine Berechtigungen verändern. Das muss der Systemadministrator vornehmen.
--- ja, genau ... wenn er das denn für mich tut. Muß er ja nicht, mir das "heilige Wurzelverzeichnis" zum Lesen freigeben nur weil Perl 5.10.0 einen Bug hat?!
Soll er mal machen. Du überbewertest die Heiligkeit zu stark, weil du dich nicht gut mit Berechtigungen und was damit zusammenhängt auskennst. Was wären die Auswirkungen von »chmod o+r /« (Setzen der Leseberechtigung für andere/»others«)? Jeder Kunde könnte die Namen der Verzeichnisse in / lesen. Welche Schlüsse kann man daraus ziehen?
* Man kann die Anzahl der Nicht-System-Verzeichnisse zählen und weiß dann, wieviele Kunden auf diesem Host angelegt wurden. Müssen ja nicht alle aktiv sein.
* Wenn die Verzeichnisnamen der Kunden nicht zufällige Zeichenketten sind (das ist bevorzugte Praxis), kann man vielleicht auf Teile der Identität der Kunden im realen Leben schließen.
* Lücken in Sicherheitskonzept der Berechtigungen werden entschleiert. Beispiel: ein Kunde hat aus irgendeinem Grund seinem Verzeichnis die Leseberechtigung für andere gegeben. Dann kann jeder reinschauen und sehen, was es dort für lustige Dateien gibt. Hinweis: diese Lücke würde schon existiert haben, würde auch somit schon ausbeutbar sein, aber durch Setzen der Leseberechtigung auf / wird sie erst klar und offensichtlich.
Ich denke, dass ist der Grund, weshalb überhaupt die Leseberechtigung auf / fehlt: der Hoster möchte Kunden vor ihrer eigenen Dummheit schützen, auch wenn es nur »security by obscurity« ist.
Ich habe mich mit dem Bug beschäftigt, um eventuell einen Workaround für dich zu erarbeiten. Im Laufe des Make-Vorgangs möchte Perl den absoluten Pfad zu sich selber ermitteln (das ist lib/ExtUtils/MM_Unix.pm Funktion Zeile 1931), und das Helfermodul lib/Cwd.pm steigt die Verzeichniskette aufwärts und die Fehlerbedingung tritt in Zeile 560 hinzu. Ich glaube, es ist nicht möglich, den absoluten Pfad zu bilden, ohne dass alle beteiligten Verzeichnisse lesbar sind - das geht aus rein konzeptionellen Gründen nicht. Sollte sich jemand von den Perl5 Porters den Bug http://rt.perl.org/rt3/Public/Bug/Display.html?id=58180 nochmal vornehmen, so vermute ich, wird er zum gleichen Schluss kommen und den Bug als WONTFIX invalidieren. Vielleicht gibt es einen Workaround, aber ich sehe ihn nicht - die P5P haben ja wesentlich mehr Erfahrung.
Du solltest die Leseberechtigung auf / unter Berufung auf dieses Bugticket einfordern.
Struppi