SymLinks werden nicht angezeigt

[LORIO]

Hi!
Ich habe einen User "ftpuser" erstellt mit dem Homeverzeichnis /home. In /home und in /home/ftpuser liegt jeweils ein Symbolischer Link auf /usr, jedoch werden diese beim Windows-Explorer (anderer PC im Netzwerk) nicht angezeigt. Sie sind jedoch unter dem MS-DOS FTP-Client sichtbar. Erreichbar sind sie auch, da der User nicht ChRooted ist.

Jetzt kommt aber das erstaunliche: Wenn ich dem User das Homeverzeichnis / gebe und dann auf /home bzw. /home/ftpuser gehe, dann sehe ich sie auch im Windows-Explorer.

Weiß jemand Rat, so dass die SymLinks angezeigt werden?

Gruß
LORIO

[VolGas]

Hi.

Benutze: "ShowSymlinks on"

BTW: was Du da beschrieben hast ist IMHO die blödsinnigste, nein, Schwachsinnigste Konfiguration,
von der ich je gelesen habe. Außerdem ist der Windows-Explorer kein FTP-Browser, er kann nur ein
klein wenig FTP - und das schlecht und falsch. Aber bei jemandem, der so das System vergewaltigt,
spielt das wohl auch keine Rolle mehr. Sorry, ich wollte Dich nicht angreifen, aber Du scheinst von
Unix null Ahnung zu haben, sonst würdest Du solchen Blödsinn nie verzapfen.

mfg.
  VolGas

[LORIO]

Jo, bin recht neu in der Unixwelt, aber versteh mich nicht falsch:
Dies war nur ne Testkonfiguration, die natürlich nicht verwendet wird.
Also auf einem kleinen Testserver, der auch nicht im Netz hängt.

Und ich werde keinem User Zugriff aufs Rootdir bzw. auf /usr geben...
Sollte nur ein Test sein, ob nachher der Symlink auf /opt oder dergleichen zu sehen ist.

Noch ne kleine Frage werden mit "HideNoAccess on" auch die Ordner/Dateien ausgeblendet, bei denen der User laut Unixrechten kein Zugriff hat?

[VolGas]

Wieso auch?
Mit "HideNoAccess" wird alles ausgeblendet, auf das der User kein Zugriffsrecht hat - sonst nix.
Siehe auch ->hier.

Vorbeugend noch einmal zu den Symlinks: wenn ein User mit "DefaultRoot" in sein Verzeichnis
eingesperrt wird (chroot), dann hilft ein Symlink auch nicht als Notausgang nach "draußen".

Idealer weise hat jeder User in seinem Homeverzeichnis das, was ihm gehört und was er braucht.
Außerhalb seines Verzeichnisses hat er nichts zu suchen. So etwas wie ein Admin-Account ist mit
FTP auch nicht zu machen, es sei denn, man ist so verrückt und hebt die Sicherheitssperren des
ProFTPD auf und loggt sich per FTP als "root" ein.

Ich schreibe das deshalb, weil Deine Fragen in diese Richtung zielen...

mfg.
  VolGas

[LORIO]

Du scheinst so genervt zu sein, dass du noch nichtmals meine Fragen richtg liest.

Noch ne kleine Frage werden mit "HideNoAccess on" auch die Ordner/Dateien ausgeblendet, bei denen der User laut Unixrechten kein Zugriff hat?

Wieso auch?
Mit "HideNoAccess" wird alles ausgeblendet, auf das der User kein Zugriffsrecht hat - sonst nix.

Meine Frage war in die Richtung: zählen bei "HideNoAccess on" nur die <LIMIT>-Blöcke oder aber auch zusätzlich die Unixrechte?

Ich Frage nämlich, weil ich es realisieren möchte, dass der User Zugriff auf sein Home aber auch Zugriff auf ein gemeinsames Userverzeichnis haben soll.


Das mit dem "Adminaccount":
So in der Art liegst du garnicht mal so falsch, denn ich bräuchte Zugriff auf mehrere Verzeichnisse: zum einen die Homedirs, den Ordner, den sich die User teilen, zum Ordner, auf dem ne Website liegt und dann noch auf /opt.
Um dies zu realisieren muss ich aber nicht erlauben, dass sich "root" einloggen darf, denn mit "DefaultRoot ~ ftpuser" kann ich das Chrooten ja auf Gruppen einschränken.

LORIO

[VolGas]

Ich habe Deine Frage schon richtig gelesen, ich konnte nur nicht verstehen, warum Du das gefragt hattest,
wo Du die Antwort doch schon kanntest. Deswegen war ich wohl auch ein wenig genervt, sorry.
Aber nun ist klar, denn an die Beschränkung von FTP-Befehlen per "<Limit>..." hatte ich nicht gedacht.
Das Wörtchen "HideNoAccess" würde ich unbedingt wörtlich nehmen - kein Zugriff, keine Anzeige.

Adminaccount:
Es stimmt schon: ohne eingeschaltetes "DefaultRoot" gibt es auch kein chroot-Gefängnis.
Aber das ist ja nur die halbe Miete: es greifen doch auch und gerade noch die Rechte des Filesystems!
Wenn ein User nicht zumindest die selbe Gruppe wie den "Admin" reinläßt, oder gar explizit die Rechte nur
sich selbst einräumt, dann hat ein sogenannter Admin absolut verloren - er kommt nicht ran, wenn er keine
root-Rechte hat.

Der ProFTPD ist wie eine Usershell zu betrachten: nach dem Einloggen hat der neu gestartete, individuelle
Prozess die selbe User- und Group-ID wie der eingeloggte User - alle Root-Rechte wurden aufgegeben.
Damit hat der ProFTPD nur noch die selben Zugriffsrechte wie der User. Das kann nicht ausgehebelt oder
umgangen, sondern nur weiter ausgebaut werden!

Also: der ProFTPD nutzt im vollen Umfang die Zugriffsrechte des Filesystems, nein, er ist ihnen sogar völlig
unterworfen. Alles, was man in der Konfiguration mit "<Limit>" zusätzlich einschränkt, sind nur FTP-Befehle,
keine eigentlichen Zugriffsrechte. Daher ist man gut beraten, wenn man mit Limitierungen in der proftpd.conf
möglichst sparsam umgeht oder besser gar nicht verwendet.

Von daher ist der Wunsch eines Admins oder Superusers nicht realisierbar - das kann (sollte!!!) man aus gutem
Grund nur als "root" über die SSH und man sollte es unbedingt vermeiden, dies per FTP tun zu wollen.
(das geht zwar, ist aber per default -zum Glück!- deaktiviert)

mfg.
  VolGas

[LORIO]

Ich habe mein ganzes Vorhaben jetzt mal durchdacht:
Das mit dem Superuser habe ich mir egtl so vergestellt:
Ich Chroote den SU (im folgenden mit <su> abgekürzt) nicht, aber verbiete ihm mit
<Directory />
  <Limit ALL>
    DenyUser <su>
  </Limit>
<Directory>
den Zugriff aufs komplette Filesystem (entsprechende Ordner werden dann explizit erlaubt)

Was ist jetzt sinnvoller? (Auch wenn beides die Sicherheit einschränkt)
Den entsprechenden Ordnern chmod xx7 zu geben
   oder
dafür sorgen, dass <su> in der entsprechenden Ownergroup ist und dann chmod x7x zu vergeben. Denke der Weg wäre sicherer, obwohl alles beide aus selbe rauskommt, wenn jmd Zugriff auf den <su> bekommt.

Bei der zweiten Methode habe ich ein Problem:
Ich möchte PAM deaktivieren, also alles über "virtuelle" User/Groups regeln, aber wie kann ich mir chown/chgrp den User/Group auf einen Namen ändern, der nicht in der passwd/group existiert. Muss ich diese dann wirklich erstellen?

Wenn ich mit GroupOwner die Gruppe eines Files auf den des virtuellen <su> ändere, hat <su> dann wirlich die GroupRechte? Also wenn <su> nicht wirklich zu der Group gehört, die im Filesystem eingetragen ist.
Also an einem Beispiel:
<su> ist in der Group "sugrp"
Der Ordner "Folder1" hat als Owner "user1" und als Group "group1" und chmod 775
Mit "GroupOwner sugrp" ändere ich die Group von "Folder1" auf "sugrp" (zumindest für ProFTPd)
Hätte <su> jetzt rwx-Rechte? Ich denke ja, weil du hast ja gemeint ich solle mir das wie eine Shell vorstellen.

Sorry, meine Fragen sind glaube ich sehr verwirrend 

[VolGas]

Stimmt. Ich habe auch wieder nicht ganz alles verstanden, aber das macht nichts.
Ich gebe Dir einfach ein paar Fakten und Du kannst dann selbst entscheiden.

* Per FTP wird alles im Klartext übertragen: Benutzername, Passwort, Daten - einfach alles.
Ein root-Account ist prinzipiell Gegenstand von sportlichen Anstrengungen gehackt zu werden,
was irgendwann gelingt's meist auch: die "Masse" macht's...

* Nur für "root" gelten keine Zugriffsrechte, alle anderen User sind diesen unterworfen.

* Per FTP kanst Du -meines Wissens- weder einen Eigentümer, noch eine Gruppe ändern.

* Rekursive Arbeiten (chown|chmod|rm -R ...) gehen per FTP überhaupt gar nicht und müssen
einzeln mühsam nachgebildet werden - das dauert und belegt unnötig Systemresourcen.

* Aber das allerwichtigste:
wenn der ProFTPD als "root" läuft und irgendwo eine Schwachstelle im System (Kernel) oder im Programm
selbst ist, hat ein potentieller Angreifer oder ein amok laufender Prozess keine "Hemmungen" mehr:
als root kann er schalten und walten wie er will...
Aus dem Grund hat der ProFTPD (und jeder andere "gescheit" programmierte Server) nur dann root-Rechte,
wenn dies unbedingt erforderlich ist. Den Rest der Zeit "fährt" er als nicht privilegierter Prozess.

Ich kann nicht verstehen, warum Du Dich so anstellst und warum eine Administration per FTP erstrebens-
werter als eine per SSH sein soll. Ich sehe keine Vorteile, nur Nachteile.
Wenn es nur um eine bequeme Benutzeroberfläche geht: es gibt z.B. den "midnight commander" (mc)...

Ich möchte mit Dir nicht über Sinn und Unsinn diskutieren und ob man nicht doch irgendwie und vielleicht...
Meine Meinung zu dem Thema und die Fakten, die mir im Moment gerade eingefallen sind, kennst Du nun.
Ich glaube, Dir fehlt im Moment einfach noch das Verständnis und der Überblick.

Wenn mein Rat und meine Erfahrung keinen Wert für Dich haben, dann ist das vollkommen ok.
Sammle Deine eigenen Erfahrungen, das ist gut.
Aber versuche nicht mit mir zu handeln.

mfg.
  VolGas

[LORIO]

Nene, ich möchte dir für deine Tipps und Hilfestellungen danken! Und das mit "GroupOwner <group>" hab ich falsch verstanden...vorhin ist mir aufgefallen, dass das nur für neu erstellte Ordner/Files gilt.

Der "Administratoraccount" sollte hat Zufriff auf alle benötigten Ordner haben (rwx). Per SSH kann ich doch keine Dateien übertragen?! Deswegen will ichs ja mit FTP machen. Der Server ist halt größtenteils ein Fileserver, der an Homeleitung hängt (Hintern nem NAT-Router). Wahrscheinlich wird er auch mal als Gameserver für LANs verwendet.
Auch wenn es dir als Unix-Guru  jetzt im Herzen schmerzen wird, aber dieses gewisse Sicherheitsrisiko kann ich aufgrund der Unbekanntheit des Servers in Kauf nehmen.

greetz
LORIO