Nee, wenn Du mit SQL arbeiten möchtest, dann laß' das ruhig!
Ich finde das eh' besser als Dutzende von Systemusern anzulegen.
Es ging nur darum, mögliche Fehlerquellen auszumerzen.

mfg.
  VolGas


PS: den "Kofler" als Urlaubslektüre? Nee, das dann doch nicht.
Zudem sollte ein Computer zur Verfügung stehen...

Sehr löblich, Du wirst es bistimmt nicht bereuen!

Wenn Du Dir die profptd.conf ->hier ansiehst, dann kannst Du erkennen, daß alle
Konfigurationsblöcke entsprechend eingerückt sind - eben um solche Fehler leicht
erkennen zu können. Aber auch nach mehrfacher Suche habe ich dort keinen Fehler
finden können. Das kann aber auch an einer sog. "Betriebsblindheit" liegen.

Schaue doch noch einmal bei Deiner Konfiguration nach, ob Du nicht aus Versehen
irgendwo ein Kommentarzeichen zuviel gelöscht oder gesetzt hast. Im Prinzip kannst
Du auch alle nicht benötigten Blöcke für SQL und TLS rauswerfen.
Und bei "Authentifikation: Standard" kannst Du die "<IfModule..."-Kapselung
aufheben - dabei aber nicht den "Kern" entfernen!

Das wird den Fehler eingrenzen.

mfg.
  VolGas

 

Aber denke daran: der Fake funktioniert nur mit FTP.
Wenn jemand mit einem Script das Verzeichnis direkt ausliest oder gar Shell-Zugang hat,
sieht er natürlich alles, wie es wirklich ist.

mfg.
  VolGas

Bitteschön!

Eines noch: vielleicht ist mit "mod_vroot " dann auch "ShowSymlinks off" interessant,
damit nicht jeder gleich den Symlink als solches erkennen kann. Damit wäre die Sicherheit
wieder etwas erhöht...

mfg.
  VolGas

@stonki:

Das hatte ich schon erwähnt, hatte aber den Link dazu nicht zur Hand.
Danke!

Gruß
  V.

Schön, daß Dir meine Beispiel-Konfig weitergeholfen hat.

Aber das ist auch für mich etwas Neues, daß ohne explizite Angabe von "SQLMinUserUID"
oder "SQLMinUserGID" derartige Default-Restriktionen wirksam sind.

Ist dem so?
Ich möchte es an unseren laufenden Servern nicht ausprobieren...

Das Einloggen auf Root-Ebene finde ich persönlich Sch...
...recklich [Ähem!].
Es gibt noch die Lösung mit dem Unix-Befehl "mount --bind ..." ein Verzeichnis in einem
anderen zu mounten (siehe auch FAQ). Das verbraucht allerdings System-Resourcen und
will ordentlich gepflegt sein.

Du könntest auch die Direktive ->DefaultChdir nutzen, um die User in ihr HomeDir zu beamen,
aber der Schutz des "DefaultRoot" fehlt damit völlig: der User kann hin, wohin er auch möchte.
Eine weitere Alternative wäre der Einsatz der "VRootEngine" (mod_vroot), das nicht ganz so
restriktiv wie "DefaultRoot" ist und Symlinks, die nach außerhalb des "Gefängnisses"
verweisen, zuläßt. Mit z.B. PHP ist solch ein Symlink aber auch ganz einfach selbst gesetzt...

Alles in Allem würde ich nicht auf "DefaultRoot" verzichten wollen - die Sicherheit des
Servers ist mir zig-tausendfach wichtiger als vielleicht eine Bequemlichkeit für den User.
Schließlich ist das für den User auch sehr wichtig. (sollte es zumindest sein!)

Kleiner Nachtrag zu vorhin: das Feld "shell" bei "SQLUserInfo" ist ein Anachronismus und
bewirkt (meines Wissens) rein gar nichts - außer Platz belegen. Wenn Du dieses durch "NULL"
ersetzt, kannst Du Dir das Feld in der Datenbank sparen. Wenn z.B. auch die Gruppe immer
die selbe sein soll, kannst Du dort auch "NULL" hineinschreiben und "SQLDefaultGID" nutzen.
Die Seite mit den Direktiven (siehe ->hier) kann sehr inspirierend sein.

Funktioniert Deine Installation nun eigentlich?

mfg.
  VolGas

Ja, mir ist das sofort ins Auge gesprungen: "DefaultRoot /"
Damit landen alle(!) User im Root-, nicht in Ihrem Homeverzeichnis und haben volle
Bewegungsfreiheit - solange die Zugriffsrechte dies zulassen. Und das tun sie wohl
nicht, was auch völlig in Ordnung ist.

"DefaultRoot ~" ist das Mittel der Wahl: es "beamt" jeden User in sein eigenes
Verzeichnis und "sperrt" ihn dann dort ein. (chroot)

Wenn es das nur war, dann können wir ja zufrieden sein, oder?

mfg.
  VolGas

Hallo!

Prinzipiell kann man das wirklich so machen (ich bleibe einmal bei Deiner Terminologie):
Systemuser aus dem System holen und wenn der User dort nicht bekannt ist, Unteruser
in der SQL-DB nachsehen.

Besser (weil übersichtlicher und zuverlässiger) wäre es jedoch, wenn alle FTP-User in
SQL zusammen administriert würden. Gleich noch eines: die Benutzung der PAM für
den ProFTPD ist nicht nur nicht notwendig, sondern nur ein zusätzlicher Aufwand und
eine weitere mögliche Fehlerquelle.

Über "mod_sql" werden Username, Passwort, Home-Dir, UID/GID an den ProFTPD weiter-
gegeben, das funktioniert sehr einfach und zuverlässig. Wenn nicht, hast Du einen Fehler
in Deiner Konfiguration. Letztendlich dürfte -bei richtigen Daten in der SQl-DB- gar kein
Unterscheid bemerkbar sein ob System- oder "Unteruser". Nur die Reihenfolge der
Authorisation solltest Du mittels "AuthOrder mod_auth_unix.c mod_sql.c" definieren.

Wenn Du weiterhin Probleme haben solltest, dann poste Deine proftpd.conf hier.

mfg.
  VolGas

Ja, da gehört es wohl am ehesten hin, Dein Posting aber eher nicht.
Vergiß aber nicht die jeweiligen Mountpoints einzurichten und es auch vorher auszuprobieren...

mfg.
  VolGas

Mann, Du machst es mir aber schwer!

Der "VirtualHost" ist wie eine separate Installation, es wird von der Ganzen proftpd.conf
nur das mitgenommen, was im "<Global>"-Block drinnen steht. Ich gebe Dir einen Tipp,
damit es jetzt funktioniert und auch schnller geht: benutze ->diese Konfiguration und
passe sie für Deine Zwecke an.

Ich vermute auch mal, daß Du Deinen Server zu Hause hast und ihn auch im Internet
verfügbar machen möchtest? Dann gelten noch zusätzliche Dinge.

mfg.
  VolGas

Ich bin mir beinahe sicher, daß Du nicht genau weißt, weshlab Du "AuthPAM" benutzt.
Deshalb: weg mit allen Direktiven für AuthPAM oder "AuthPAM off" - das System macht
das schon selbst ganz gut. Ebenso "AuthGroupFile /etc/group" - das verwendet schon
das System, das ganze über ein zusätzliches Modul (auth_file) ist unsinnig, weg damit.
Am Ende Deiner proftpd.conf hast Du ein Include-File definiert, dieses aber nicht hier
gepostet. Verzichte auf Includes und hänge den Inhalt dieser Datei an das Ende Deiner
proftpd.conf.

Fehler in Zeile X usw.

Na Du bist mir vielleicht ein Held!
Ausgerechnet das, was wichtig ist und helfen würde, ist Dir egal.
Na ja, dann kann mir das ja auch egal sein.

Ändere Deine .conf und starte den ProFTPD neu.
Sollte der Fehler bleiben, so starte ihn im Debug-modus neu (näheres siehe FAQ!),
verwerfe die Debug-Ausgabe bis dahin und logge Dich wieder ein. Poste dann die
Debug-Ausgabe ab dem Login wieder hier.

mfg.
  VolGas

Hallo!

Na, opfern tu ich mich nicht, aber ich kann versuchen zu helfen...
Und lassen mit ProFTPD mußt Du es auch nicht - der läuft -zigtausend mal auf eben
so vielen Maschinen problemlos. Warum also nicht auch bei Dir.

Ok, Deine proftpd.conf scheint soweit in Ordnung, ich möchte nur etwas anmerken:
den Standard- bzw Default-Server kannst Du nicht verhindern, nur den Zugang dazu.
Der "anonymous"-Zugang ist schließlich ein Teil des Standard-Servers.

So, nun aber zur Sache:

• Ich gehe davon aus, daß Du den ProFTPD ohne die SQL-Erweiterung compiliert hast.
• in Deinem Unix-System müssen für diese Konfiguration die User "ftp" und "nobody"
  als auch die Gruppen "ftpuser" und "nogroup" definiert sein - ggf. anlegen oder die
  proftpd.conf ändern.
• der Pfad zu Deinem "anonymous"-Verzeichnis muß für den User "ftp" offen sein -
  bitte Zugriffsrechte überprüfen!!!
• Deinem ersten Zitat zufolge könnte man entnehmen, daß Du versucht hast, Dich als
  User "ftp" einzuloggen. Das ist allerdings ein regulärer User, der auch dessen reguläres
  Passwort benötigt. Einloggen als "anonymous" funktioniert wirklich nur als User
  "anonymous". Der muß allerdings nicht im System angelegt sein, dafür wurde ersatz-
  weise User "ftp" definiert

Nachdem Du das alles beachtet und kontrolliert hast, starte den ProFTPD sicherheitshalber
neu und versuche es noch einmal.

Ich hoffe Du kommst damit weiter und könntest damit Dein Problem Lösen.
Falls es jedoch weiterhin nicht funktionieren sollte, so poste hier die Fehlermeldung aus
Deinen Logfiles oder, wenn dort nichts verwertbares zu finden ist, stoppe den ProFTPD,
starte ihn erneut im Debugmodus und poste dann die Ausgabe ab dem Zeitpunkt des
Loginversuchs. (siehe auch ->FAQ, "ProFTPD startet nicht...")
Die Fehlermeldungen des FTP-Clients helfen i.d.R. gar nichts.

mfg.
  VolGas

Hallo!

Den ProFTPD mußt Du wie eine Unix-Usershell versehen: nachdem man sich eingeloggt
hat, hat der für eigens reservierte Prozess nur noch die Zugriffsrechte und Beschränkungen
wie man selbst. Die Zugriffsrechte des darunterliegenden Filesystems sind absolut bindend
und können nicht "verbogen" oder gar außer Kraft gesetzt werden - es können nur zusätzliche
Restriktionen per FTP (z.B. Schreib- und Lesesperren) und einige "kosmetische Korrekturen"
realisiert werden.

Außerdem wird nach dem Einloggen zusätzlich ein "chroot" durchgeführt, d.h. man wird quasi
in sein Home-Dir "eingesperrt", das Home-Dir wird zu Root-Dir - es gibt "außenherum"
nichts mehr, man ist isoliert. Daher kann man (normalerweise) mit Symlinks nicht aus
seinem chroot-Gefängnis ausbrechen.

Dafür gibt es unter UNIX eine Not-Lösung, (siehe ->FAQ, Punkt "...Verzeichnis einbinden...")
die man IMHO aber sehr sparsam und mit bedacht einsetzen sollte. Für einen User
(wie den anonymous) und zwei/drei Verzeichnissen sollte sich das allerdings noch vertreten
lassen.

Zum Thema "VirtualHost": Du verwechselst den ProFTPD mit dem Apache - böser Fehler!
Beim ProFTPD gibt es den "Haupserver", der durch die normale Konfiguration definiert
wird und einfach da ist. Bis dahin gleichen sich die beiden Server noch.

Ein "VirtualHost" in ProFTPD jedoch definiert -anders als Apache!- einen weiteren,
zusätzlichen Server auf einer anderen IP oder Port!

Diese wesentlichen Punkte beachtend solltest Du nun Deine Konfiguration überarbeiten.
Es sind so viele Änderungen vorzunehmen, daß Du am besten den letzten Block einfach
entfernst und neu schreibst. Ein schönes Muster für eine anonymous-Konfiguration hast Du
ja auch schon in Deiner proftpd.conf, Du müßtest Sie nur etwas überarbeiten und
"ent-kommentieren"...

mfg.
  VolGas

Moin,

netter Versuch, aber so geht's wirklich nicht.
In der proftpd.conf sollte (unbedingt!) die Direktive "DefaultRoot ~" stehen.
Das "beamt" den User in sein Verzeichnis und "sperrt" ihn aus Sicherheitsgründen
auch gleich dort ein (chroot). Das ist gewollt und auch gut so.

Du kannst den ProFTPD wie eine Usershell sehen: nach dem Einloggen gibt dieser
seine Root-Rechte auf und hat dann nur noch Deine Zugriffsrechte. Ohne Ausnahme.

Entweder Du legst Dir einen zweiten Account an (beste Lösung) oder Du mountest
ein Verzeichnis in dem anderen. Siehe dazu auch die ->FAQ's (Punkt acht) auf
Stonki's Website.

mfg.
  VolGas

Damit kann man schon etwas anfangen.
Aber warum wiederholen sich die Anweisungen in der .conf immer wieder?
Egal, müßte auch so funktionieren.

Dieses "UserPassword ..." mache mal ganz schnell wieder raus...

Deine proftpd.conf sollte zumindest so weit sein, daß eine Verbindung über das
lokale Netzwerk funktionieren sollte. Siehe mal nach, ob das geht und wenn nicht,
ob der Prozess überhaupt läuft. (ps auxf | grep proftpd)

Dann möchtest Du ja, daß der Server sowohl lokal (LAN) als auch im Internet (WAN)
erreichbar sein soll. Diese proftpd.conf jetzt soweit zu umzukonfigurieren und alles
erklären geht jetzt zu weit - versuche es einmal ->damit.

Jetzt mußt Du folgendes anpassen:

• Deine Servermaschine benötigt eine zweite IP. (für LAN)
• den Router / die Firewall mußt Du etwas modifizieren: der Port 21 und die
  Ports 49152-65534 (high ports) müssen unverändert an der Servermaschine ankommen.
• das proftpd.conf-Muster muß angepasst werden:
  
  • "MasqueradeAddress" ist zu aktualisieren und zu aktivieren
  • "DefaultAddress" ist auf die IP-Adresse der Netzwerkkarte zu aktualisieren (für WAN)
  • "<VirtualHost...>" auf die zusätzliche IP aktualisieren (für LAN)
  • sonstige Anpassungen wie z.B. "ServerAdmin"
• proftpd neu starten

Fertig - so sollte alles funktionieren!
Noch etwas: FTP-Clients bitte immer im passive mode!
Und: solltest Du jetzt auf "dumme" Gedanken gekommen sein: TLS erst, wenn alles funktioniert...

mfg.
  VolGas