Hallo,

wenn Du schon mein Konfigurationsmuster benutzt, dann verstümmle es doch bitte nicht:
Du hast Sachen aus dem Zusammenhang gebracht und dadurch vielleicht auch den Fehler
herausgefordert. Du schließt z.B. den "<Global>"-Block vorzeitig und benutzt Direktiven
mehrmals. Um die Zusammenhänge besser zu erkennen, solltest Du Dir das eingerückte
Muster ->hier noch einmal ansehen. Am besten, Du machst Deine proftpd.conf noch einmal
neu aus diesem Muster. Wiklich neues hast Du ja nichts hinzugefügt.

Aber ehrlich gesagt: die Direktive "AllowRetrieveRestart" ist gesetzt und so sollte
der ProFTPD eigentlich funktionieren. Ich kann es mir zwar nicht vorstellen, aber vielleicht
hängt dies wirklich an der falschen "Klammerung" von "<Global>"...

mfg.
  VolGas

Was willst Du da eigentlich noch ausführlicher haben?
Das ist eigentlich schon alles!

Jetzt kommt die Stelle, an der ich Dir leider sagen muß, daß man zumindest die absolut not-
wendigsten Grundkenntnisse von einem Linux-System haben sollte, bevor man dort anfängt,
etwas ändern oder einrichten zu wollen. Ein Teil Deiner Fragen gehören zu den Linux-Grundlagen,
die hier eigentlich als vorhanden vorausgesetzt werden nicht weiter behandelt werden sollten.

Ich kann Dir für den Anfang wärmstens z.B. das Standardwerk, den ->"Kofler" empfehlen,
es gibt aber auch sehr viel weiterführende Literatur im Internet...

So nachdem ich das getan habe: hier im Forum habe ich mich mit zwei Postings etwas näher
mit dem Compileren des ProFTPD ausgelassen, die Dir vielleicht ein wenig weiterhelfen können.
Siehe ->hier und ->hier. Weiteres über die "Suche"-Funktion des Foren-Systems...

Ich hoffe, Du kommst damit ein Stückchen weiter...

mfg.
  VolGas

Hallo!

Die Direktive "DefaultRoot" dient dazu, den User in ein Verzeichnis "einzusperren" (chroot).
Wenn dies nicht sein Homedir ist, dann kann er natürlich innerhalb dieser Verzeichnisstruktur
herumspazieren wie er will und es die Zugriffsrechte erlauben.

Damit der User ausschließlich in seinem Homedir ist (und bleibt!), muß "DefaultRoot ~"
verwendet werden. Andere Verzeichnisse außerhalb davon sind dann eine Sache von entweder
individuellen mount's oder von separaten FTP-Accounts. Es gibt noch eine Möglichkeit,
"DefaultRoot" aufzuweichen - die "VRootEngine". Siehe ->hier und ->hier.
Da das Ganze aber darauf beruht, daß Symlinks das chroot-Gefängnis durchbrechen können,
ist diese Methode nur bein reinen FTP-Accounts sicher. Mit Shellzugang oder Scriptsprachen wie
z.B. PHP wäre dann die ganze Absicherung nutzlos und für die Katz.

Meine Meinung: für unterschiedliche Verzeichnisse, die außerhalb des eigenen Homedirs sind,
immer eigene FTP-Accounts anlegen. Das ist zwar nicht so anwenderfreundlich, aber darum
geht es bei Sicherheitsfragen einfach nicht.

Zu den Zugriffsrechten habe ich noch einen Textbaustein für Dich:

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!

Was mir bei Deiner recht ordentlichen proftpd.conf noch aufgefallen ist:

• Die Direktiven "SQLDefaultUID" und "SQLDefaultGID" überschreiben Deine UID/GID Werte
  aus Deiner Datenbank. Das wirst Du wohl nicht wollen: entfernen oder auskommentieren.
• Angaben, die Du in der Datenbank nicht führen möchtest, kannst Du bei "SQLUserInfo" durch
  "NULL" definieren. Damit kann man z.B. das IMHO absolut überflüssige Feld "shell" abhaken.
  Und: wenn alle User die selbe GID haben sollen, kann man dies dem entsprechend auch
  einsetzen. Dafür nutzt man dann (!) zusätzlich "SQLDefaultGID"...

Zu Deinen Fragen konnte ich Dir leider nur eine etwas unbequeme Lösung bieten,
aber ich hoffe, Du kommst damit dennoch ein Stück weiter.

mfg.
  VolGas

Hallo!

Du mußt schon selbst etwas nachsehen:
siehe Konfigurationsdirektiven ->MaxClients, ->MaxClientsPerHost, ->MaxClientsPerUser, etc.
und ->TransferRate.

Ein Tipp: siehe auch die ->Beispiel Konfigurationen; speziell die ->Standard Deluxe Version
greift alle "normalen" Vorkommnisse und Bedürfnisse ab.

Ich hoffe, Du kommst damit weiter.

mfg.
  VolGas

Ja, die Direktive "DenyGroup !admins" sperrt alle User bis auf die der Gruppe "admins" aus.

Ok, ich habe nun Dein Posting noch einmal ganz genau durchgelesen und muß mich entschuldigen:
um Zeit zu sparen habe ich wirklich zu oberflächlich durchgelesen. Jetzt aber richtig:

Du beschreibst in Deiner Struktur drei Verzeichnisse, die alle direkt unter "/home" liegen sollen.
Was mich sofort gewundert hat: Du schreibst, daß das Home-Verzeichnis Deines Users
"/home/ftp" sei - aber gleichzeitig soll dieser User außerhalb seines Home-Verzeichnisses
trotz "DefaultRoot ~" Zugriff haben. Das alleine dürfte schon einmal nicht gehen.

Damit der von Dir definierte User tatsächlich auf die erwähnten Verzeichnisse zugreifen kann,
müßten diese alle in "/home/ftp" angelegt sein. Ich gehe nun davon aus, daß das wohl so ist.

Wie aber auch immer: In dem von Dir geposteten Konfigurations-Auszug sind andere Pfade definiert!
Diese sind immer absolut anzugeben, können aber auch mit "~" für das aktuelle Home-
Verzeichnis beginnen. Dann hätte jeder User separat diese Definitionen für jeweils diese
Struktur.

Fazit: kontrolliere Deine Verzeichnispfade in Deiner Konfiguration, damit diese auch der realen
Situation entsprechen. Der ProFTPD hat alles richtig gemacht!

mfg.
  VolGas

Hallo!

Ich bin gerade zufällig darauf gestoßen: http://proma.sourceforge.net/
Keine Ahnung, wie das aussieht, ob es etwas taugt (oder auch nicht)
und was man damit alles kann - ich kenne das Teil nicht.

Nach kurzem Überfliegen könnte es der Beschreibung nach aber das sein, was Du suchst.

mfg.
  VolGas

Moin!

So funktioniert das nicht, das hast Du ja schon bemerkt.

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!

Es gelten also als allererstes die Zugriffsrechte des Filesystems, mit <Limit...>-Anweisungen
schränkt man nur zusätzlich noch die Benutzung der FTP-Befehle ein. Weiterhin sollte man mit
"DefaultRoot ~" den jeweiligen User in sein Home-Verzeichnis "beamen" und dort einsperren
lassen - Stichwort: chroot.

Der Wunsch eines Admins oder Superusers ist auch nicht realisierbar - das kann 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

Ich gehe davon aus, daß auch der ProFTPD neu aufgespielt wurde.
Die Ausgangssituation ist softwareseitig nun eine ganz andere, d.h. der Fehler kann
nur in der Filestruktur (Zugriffsrechte) liegen. Das scheint mir ziemlich eindeutig.

Der ProFTPD läuft nun unter dem inetd (siehe "ServerType").
Besser wäre, meiner Ansicht nach, er würde wieder als "standalone" laufen.
Dazu mußt Du ihn aus der Datei "/etc/inetd.conf" austragen und den Daemon neu starten.
Dann noch ein Start/Stop-Script für den ProFTPD installieren und er ist wieder eigenständig.

Für den Debug-Modus startest Du ihn aber manuell mit den Parametern: -nd5

mfg.
  VolGas

Ok, wenn das durchgehend gesetzt ist...
Entferne noch den "<Limit ...>"-Block und starte den ProFTPD neu.

Wenn das auch nichts geholfen hat, dann starte den ProFTPD neu im Debug-Modus (-nd5).
Verwerfe die Ausgabe und starte eine neue Session mit einem Upload.
Die Ausgabe dann bitte hier posten.

mfg.
  VolGas

Hallo!

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!

Daher ist Dein Wunsch keine Rechte im FileSystem verwenden zu wollen, nicht machbar.
Virtuelle User sind kein Problem, das funktioniert z.B. mit einem File strukturiert wie /etc/passwd
(mod_file), mySQL & PostgreSQL (mod_sql), cdb, LDAP, etc...

Da es dem FileSystem "egal" ist, ob zu einer bestimmten UID/GID einen entsprechenden User
bzw. Gruppe gibt, kann man beliebige ID's zuweisen - wenn es sein muß, auch jedem User die
selbe. Mit der Direktive "DefaultRoot ~" beamt man jeden User in sein eigenes Home-Verzeichnis
und sperrt ihn damit auch gleichzeitig ein. (Stichwort: chroot)

Macht man das nicht, so kann jeder User im Filesystem "herumspazieren" und sich alles ansehen,
und wird nur durch die jeweiligen Userrechte des Systems zurückgehalten. Möchte man ein weniger
restriktives "chroot", d.h. eines, das Symlinks aus dem Gefängnis als Ausgang zuläßt, gibt es
noch das Modul für die "VRootEngine", das man mit in den ProFTPD hinzucompilieren lassen kann. (siehe ->hier)
Vorsicht: wenn allerdings der User selbst Symlinks anlegen kann (Stichwort: Scriptsprachen wie
z.B. PHP), dann ist die VRootEngine auch kein Schuß Pulver mehr wert und alles war für die Katz'.

Am besten, Du überlegt Dir eine gute Dateistruktur, benutzt "DefaultRoot" um den User auf den
untersten Level Deines Verzeichnisbaums zu begrenzen und schickst ihn dann mit ->DefaultChdir
als Ausgangspunkt in sein eigenes Homeverzeichnis, von dem aus er dann herumwandern kann.

Sonst sehe ich keine andere Möglichkeit das so zu realisieren, wie Du Dir das vorsgestellt hast.
Ich hoffe dennoch, daß ich Dir damit weiterhelfen konnte.

mfg.
  VolGas

Jetzt stellt sich für mich die ewige Streitfrage: warum Passworte verschlüsselt speichern?
Das übertriebene Getue um "Sicherheit" ist reine Augenwischerei: wenn ein System selbst
so schwach gesichert ist, daß dort eingebrochen werden kann, dann hilft es auch nichts,
daß dort hinterlegte Passworte verschlüsselt sind. Mal abgesehen von dem Supportaufwand
und Kundenzufriedenheit bei vergessenem Passwort...

Aber egal, zu Deiner Frage: wenn Du die Doku gelesen und dort den Parameter "OpenSSL"
gefunden hast, dann hast Du ab dieser Stelle nicht weitergelesen. Präziser als die deutsche
Beschreibung ist die Englische:

OpenSSL
Allows passwords in the database to be of the form '{digest-name}hashed-value', where hashed-value is the base64-encoded digest of the passsword. Only available if you define HAVE_OPENSSL when you compile proftpd and you link with OpenSSL's libcrypto library.

Das kann zwar mit der PHP-Funktion "md5" zu tun haben, wäre aber nur ein Teil der Miete.
Hier müßtest Du den Hex-kodierten Rückgabewert zunächst wieder zurückrechnen lassen und
dann in base64 umwandeln. Und: hast Du tatsächlich den ProFTPD mit der SSL-Library zusammen-
compilieren lassen?

Einfacher wäre -wenn es schon sein muß!- "SQLAuthTypes Crypt", was der anderen Methode
in etwa gleich kommt. Mit PHP läßt sich dann das zu speichernde Passwort so verschlüsseln:
"crypt($passwort, '$1$dasGeheimnis')" oder besser: "crypt($passwort, '$1$' . mt_rand(10000, 99999999))"
Du kannst natürlich die Funktion "crypt()" auch ganz alleine gewähren und den sichersten
Algorithmus selbst aussuchen lassen.

Ich hoffe, ich konnte Dir damit weiterhelfen...

mfg.
  VolGas

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.

Du mußt also darauf achten, daß Deine Zugriffsrechte im Filesystem immer stimmen, dann
klappt das auch immer mit dem ProFTPD - selbst mit solch einer minimalen Konfiguration.

mfg.
  VolGas

Eigentlich sollte "DefaultRoot" auf "~" gesetzt werden - damit kommt jeder User
in sein Verzeichnis und wird darin eingeschlossen. (chroot)

Setzt man "DefaultRoot" auf "/", dann landet natürlich jeder User dort und kann
dann ganz nach belieben im Filesystem "spazieren" gehen.

mfg.
  VolGas

Die verschiedenen <Anonymous ...>-Blöcke waren vielleicht nur eine Aneinanderreihung von
Beispielen. Mit Deinem weiteren Vorgehen hast Du eigentlich den Sinn eines "anonymous"-Users
zu einem normalen User pervertiert. Aber wenn Du damit zufrieden bist...

mfg.
  VolGas

Jetzt verstehe ich zumindest die Struktur - wozu das gut sein soll, bleibt mir
allerdings ein Rätsel. Daß ichz das verstehe ist aber auch für den Fall nicht relevant.

Was haben die User jeweils für ein eingetragenes Homedir und worauf was hast Du
"DefaultRoot" gesetzt?

Vielleicht postest Du auch einmal Deine proftpd.conf...

mfg.
  VolGas