RTFM, z.B.: http://www.proftpd.de/Support.13.0.html  :roll:

mfg.
  VolGas

Log Dich als entsprechender User oder als root (Vorsicht!!!) ein.

Die elementaren Grundkenntnise von Linux/Unix sollten eigentlich zum Arbeiten vorhanden sein...!

mfg.
  VolGas

Hallo Volker,

im Standalone-Modus ist es so, daß (normalerweise) ein Serverprozess mit root-Rechten läuft und beim einloggen eines Users ein child-Prozess gestartet wird, der dann sofort seine Root-Rechte aufgibt und UID und GID wechselt. Das ist schon richtig so.

Mit dem inetd zu arbeiten finde ich nicht so gut, deswegen bin ich mir nicht sicher, ob meine Antwort stimmt: der inetd übernimmt komplett die Kontrolle und startet die entsprechende Prozesse mit vordefinierter UID selbst.
In wie weit ein Serverprozess dann noch Möglichkeiten hat, Einfluß zu nehmen und ggf. sogar UID und GID zu wechseln, weiß ich nicht.

Ich kann nur empfehlen, was auch in der Doku steht: benutze den Standalone-Modus!

Zu 2:
Hier fehlt Hintergrund, sprich: die config.

Aber soviel kann ich sagen, denn ich diese Falle bin ich selbst auch getappt: ist der eingeloggte User Eigentümer des "umgebenden" Verzeichnisses, so hat dieser immer das Recht auch fremde Dateien in seinem Verzeichnis zu löschen - auch wenn die Userrechte formal fehlen sollten.

Wie man per FTP allerdings einen Link ändern können soll (geht nicht!?), entzieht sich meiner Kenntnis - zumal daß Links normalerweise keine eigenen Rechte besitzen und immer mit "rwxrwxrwx" angelegt werden. Wirklich greifen ja erst die Rechte der Zieldatei...

mfg.
  VolGas

Hallo "moods",

ich vermute, daß es an der Einstellung "TLSVerifyClient on" liegt.
Da muß sich der Client nämlich ebenfalls mit einem gültigen Zertifikat beim Server authentifizieren - und das hat wohl gefehlt.
Das Ganze wird dann nämlich auch schon etwas komplizierter...

Den Einsatz von "TLSRequired on" würde ich allerdings beim nomalen Betrieb nicht empfehlen wollen...

mfg.
  VolGas

Wie blöd muß man denn sein, wenn man nach einer Stunde eine Antwort
von einem freien Forum erwartet und dann auch noch die Leute
dumm anmacht und beschimpft, wenn diese Antwort in der kurzen Zeit
ausbleibt?

Ich denke mal, daß meine wohl die einzige sein wird.
Und ich bin mir sicher: wenn jemand die Antwort gewußt hätte,
dann wäre diese in spätestens ein/zwei Tagen hier gepostet gewesen.

"stonki" und "Wörsty" betreiben diese Site und dieses Forum auf eigenen Antrieb und
auf eigene Kosten und geben selbstlos kostenlosen und kompetenten Rat.
(Dafür möchte ich hier einmal stellvertretend sehr herzlich bedanken!)

Aber (anonyme!) Blödmanner wie Du sind schuld daran, wenn solche Leute die Lust verlieren und
damit die "Idee" des Internets, anderen kostenlos und selbstlos zu helfen, kaputt geht.

@all: Sorry wegen des Flamings, aber ich konnte mich gerade nicht mehr zurückhalten!

mfg.
  VolGas

Hi!

IMHO ist Deine conf eher etwas "ungewöhnlich" und könnte noch etwas überarbeitet werden, aber das soll jetzt keine Rolle spielen.


Ersetze doch zunächst einmal <Anonymous ~ftp> mit <Anonymous /data>
Damit dürfte zunächst einmal Dein "Anonymous"-Zugang funktionieren.

Da die Authorisation sonst per Default über Unix-PAM läuft und für "famiglia" keine weiteren Einträge in der Config vorhanden sind, muß ich vielleicht etwas dumm fragen: sind die entsprechenden FTP-User der "famiglia" auch als Unix-User eingetragen und die der Unix-Gruppe "famiglia" zugewiesen?

Was soll außerdem mit den "restlichen" Unix-Usern passieren?
Dafür gibt es keinen Eintrag... (= Sicherheitslücke!)


mfg.
  VolGas

Hmm, die config würde ich doch noch einmal bearbeiten.
IMHO ist "Servertype inetd" nicht gerade "optimal"...

Vor allem fehlt noch: "DefaultRoot ~" für den Login.

Ein recht schönes Konfigurationsbeispiel findet sich auf Stonki's Site...

mfg.
  VolGas

No Problem - ich fühlte mich nicht belästigt.
Mich interessiert allerdings hinterher immer, ob und wie die Sache funktioniert hat...?

mfg.
  VolGas

Meiner Meinung nach sind die die normalen Unix-Zugriffsrechte im Weg.
Ich denke, wenn Du die Dateien/Verzeichnisse für jeden Schreib- und Lesbar gemacht hast, sollte das auch mit dem Upload klappen.

Daß nach einer FTP-Session alles auf den selben User / die selbe Gruppe definiert sein soll, geht meiner Meinung nicht, solange die User sich als "normale" Systemuser einloggen. So hat nämlich jeder seinen ganz spezifischen Rechte, über die sich ProFTPD nicht hinwegsetzen kann.

Eine einfache, schnelle Lösung:
Benutze in der Config die "GroupOwner" Anweisung.
Dann müssen nur noch alle entsprechenden User als Mitglied der gewünschten Gruppe eingetragen werden.
Es werden dann allen neuen Dateien/Verzeichnisse der gewünschten Gruppe zugewiesen.
Die richtige umask rundet das Ganze ab.
In Kombination von UserOwner kann das Ganze noch weiter vereinfacht werden - die eigenen Userrechte werden dann vor dem chroot aufgegeben und der FTP-User wechselt nach dem Einloggen endgültig seine Identität.

Eine zweite Lösung:
eine andere Authentifikationsmethode als die des Systems/PAM benutzen und dann jedem User die selbe UserID und GroupID zuweisen.
Der Weg ist etwas länger, da wohl ProFTPD neu zu kompilieren ist und eine neue Usertabelle angelegt (und gepflegt) werden muß, aber nur so hat man wirklich die volle Kontrolle und muß nicht für jeden FTP-User einen System-User anlegen.

mfg.
  VolGas


PS: manchmal hilft es ungemein, sich die Doku anzusehen - da kommt man oft weiter, auch ohne fragen zu müssen.
Diesen "Weg" bin ich für meine Antwort auch gegangen und konnte dadurch wieder etwas lernen. Danke...

Hi,

die Fehlermeldung ist klar und die Lösung relativ einfach: der Compiler findet die Sourcen/Libraries von mySQL nicht, die er für die Schnittstelle zu mySQL braucht.

Unter Debian kann man sich aber die Sache recht einfach machen und über "apt-get install proftpd-mysql" alles fertig installieren lassen.
Damit werden alle Abhänigkeiten berücksichtigt und entsprechendes installiert - das ist sehr bequem und ein selbst compilieren ist so nicht nötig.

Es macht mitunter aber dennoch Sinn, seine Softwarepakete in einem Debian-System selbst zu compilieren, da Debain -sehr diplomatisch ausgedrückt- nicht unbedingt immer die aktuellsten Versionen installiert und man zusätzlich keinen Einfluß auf einkompilierte Optionen hat.
Man muß nur aufpassen, daß man der Paketverwaltung von Debain "aus den Füßen" bleibt und sich nichts gegenseitig ins Gehege kommt.

Will man ProFTPD unter Debian selbst compilieren, so müssen dem Compiler/Linker die Pfade mitgeteilt werden, wo die Sourcen/Libraries von mySQL zu finden sind und wohin man seine Installationen haben möchte.

Das geht z.B. so:

Code:

./configure \
--with-modules="mod_sql:mod_sql_mysql:mod_tls" \
--disable-auth-file --disable-auth-pam \
--disable-sendfile --enable-buffer-size=8092 \
--with-includes=/usr/local/mysql/include/mysql \
--with-libraries=/usr/local/mysql/lib/mysql \
\
--prefix=/usr/local/proftpd-1.2.10 \
--sysconfdir=/etc --localstatedir=/var/run --mandir=/usr/local/man

make
make install

Das ist natürlich nur eine Möglichkeit, wie man sein ProFTPD compilieren kann.
Zu Achten ist jedoch immer auf die richtigen Pfadangaben bei "--with-includes=..." und "--with-libraries=...".
Dann sollte alles klappen.

mfg.
  VolGas

Wenn der Login klappt und dennoch kein Listing erscheint, könnte das an den Rechten des Verzeichnisses liegen. (execute, no read)

mfg.
  VolGas

RTFM:

http://www.proftpd.de/HowTo_SFTP_TLS_verschluesse.55.0.html
http://www.pro-linux.de/t_netzwerk/burn-ftp-burn.html
http://www.debianhowto.de/de:howtos:sarge:proftpd_tls
http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-TLS.html
etc...

;-)


So (in etwa) ist es bei uns eingerichtet:

Code:

TLSEngine                       on
TLSProtocol                     SSLv23
TLSTimeoutHandshake             60
TLSRequired                     off
TLSVerifyClient                 off

TLSOptions                      NoCertRequest
TLSLog                          /var/log/proftpd/tls.log
TLSRSACertificateFile           /etc/ssl/certs/proftpd.cert.pem
TLSRSACertificateKeyFile        /etc/ssl/certs/proftpd.key.pem
#TLSCACertificateFile           /etc/ssl/certs/whoever.cert.pem

mfg.
  Volgas

Nö: Permission denied

Egal - ich will so etwas ja nicht und wir brauchen das auch nicht.

Aber schön, daß es bei Dir nun funktioniert.

mfg.
  VolGas

Ich muß mich korrigieren: es funktioniert nicht!
Entweder man kann überall schreiben oder gar nicht - zumindest ist das so auf unserem Server.

Ich hatte vorhin ganz vergessen, daß noch ein weiterer Sicherungsmechanismus das Schreiben unterhalb eines Home-Verzeichnisses verhindert.

Sorry!

Vielleicht ist aber nur meine Vorgehensweise mit den "LIMIT"-Direktiven falsch - weiß es jemand besser?

mfg.
  VolGas

Ich habe es doch noch ausprobiert und: es funktioniert tatsächlich!

Der User landet zwar zuerst in seinem Home-Verzeichnis, kann sich aber nach unten "durcharbeiten".
Sonst wie gewünscht.

mfg.
  VolGas