Hier geht es um ganz normale Unix-Zugriffsrechte.

Das Problem läßt sich sehr leicht lösen:
* jedem User eine eigene User-ID
* alle in einer gemeinsamen Gruppe
* in proftpd.conf: umask 033 022
* schon existierende Dateien/Verzeichnisse mit "chmod" entsprechend anpassen

Die Einstellung von "umask" ist "umgekehrt" wie chmod und bewirkt hier folgendes:
* Der Eigentümer einer Datei / eines Verzeichnisses hat immer vollen Zugriff.
* Dateien: die Gruppe darf lesen - nicht schreiben (2 = write), nicht ausführen (1 = execute).
* Verzeichnisse: die Gruppe darf öffnen und lesen, nicht schreiben (2 = write)
* Alle "anderen" (damit auch ein Webserver) haben die selben Rechte wie die Gruppe.
Falls die Dateien per Webserver erreichbar sein sollen kann man natürlich alle User in die Gruppe des Webservers "stecken".
Dann entfiele das Anlegen einer zusätzlichen Gruppe und damit die Userverwaltung.
"umask" wäre dann: 037 027

Damit dürfte alles wünschgemäß funktionieren...

mfg.
  VolGas

z.B. so:

/usr/local/proftpd -nd 3

Meldungen werden über die Konsole ausgegeben.
Beenden mit CTRL-C.

mfg.
  VolGas

Wie schon geschrieben: wenn ProFTPD mit mySQL-Support compiliert und im Einsatz ist, kann man seine Accounts (User, PW, Pfade, etc.) per Webbrowser via phpMyAdmin administrieren.

Der SSH-Zugang wird dazu nicht benötigt.

Eine recht gute Anleitung dazu gibt es auf Stonki's Website, jedoch müßte man die grundlegenden Prinzipien eines Linux-Systems kennen.

mfg.
  VolGas

Ich glaube, "Stonki" hat den Fehler erkannt.

Füge einmal "AuthOrder mod_auth_file.c" in dein Konfigurationsdatei ein.
Wie die Datei "proftpd.auth" aussehen müßte weiß ich nicht, aber mit dem richtigen "AuthOrder" sollte Dein Problem gelöst sein.

mfg.
  VolGas

Das dürfte sehr schwer, wenn nicht gar unmöglich, werden.

Für PHP gibt es aber eine Möglichkeit, eigenen Code vor jedes Script vorzuschalten:
In der "php.ini" kann mit dem Setting-Parameter "auto_prepend_file" eine Datei angegeben werden, die automatisch vor jedem PHP-Script eingefügt wird.

Siehe: http://www.php.net/manual/en/ini.core.php#ini.auto-prepend-file

Ich hoffe, das hilft weiter...

mfg.
  VolGas

Hallo Stonki,

1.) vielen Dank für Deine Antwort und Deine Geduld
2.) Du hast Recht!

Zu meiner Schande muß ich gestehen, daß ich die Funktionsweise des "Sticky Bits" nicht ganz "ausgelotet" hatte und im Vorfeld meines Postings es auch nicht noch einmal im o.g. Kontext ausprobiert hatte.

Ich habe mich nun noch einmal "duchgelesen":

Das Sticky Bit bei einem für alle zum Schreiben geöffneten Directory verhindert, daß sich Benutzer gegenseitig die in einem offenen Verzeichnis abgelegten Dateien weglöschen. Typische Anwendungen dieser Ausnahmeregelung sind die Verzeichnisse /tmp und /var/tmp. Ein solches Verzeichnis muß für alle zum Schreiben geöffnet sein.

Ist das Sticky Bit auf einem solchermaßen schreiboffenen Verzeichnis gesetzt, so darf man in diesem Verzeichnis nur löschen oder umbenennen, wenn eine der folgenden Bedingungen erfüllt ist:

* Die effective uid des löschenden oder umbenennenden Prozesses ist die des Eigentümers der Datei
* Die effective uid des löschenden oder umbenennenden Prozesses ist die des Eigentümers des Verzeichnisses
* Die Schreibberechtigung der zu löschenden oder umbenennenden Datei ist so freizügig gesetzt, daß man die Datei selbst beschreiben darf
* man ist "Superuser" root

Ich ging fälschlicherweise davon aus, daß das Sticky Bit prinzipiell verhindert, daß fremde Dateien gelöscht werden können, wenn man keine Schreibrechte an diesen hat. ProFTPD macht allso alles richtig...

Ich muß mir eben etwas anderes einfallen lassen, vielleicht in dieser Art:

Code:

<Directory ~>
    HideFiles "^__system"
</Directory>

Damit könnte ich dann wichtige Files (oder gar ein ganzes Verzeichnis) vor dem User recht gut verstecken - es sei denn, er weiß, wo er zu suchen hat oder er liest per Script das Verzeichnis aus.

Es ist mir peinlich und tut mir leid, Dich mit meiner Frage "belästigt" zu haben, aber vielleicht kommt irgendwann wieder so ein "Schlaumeier" wie ich - dann kannst Du ihn gerne auf diesen Artikel verweisen...

Vielen herzlichen Dank auch dafür, daß es dieses offene Forum gibt und auch so hervorragend von Dir unterhalten wird!

mfg.
  VolGas

Hallo Stonki,

vielen Dank für Deine Antwort.
Das von Dir erwähnte Posting hatte ich bei meiner Suche gar nicht gefunden oder übersehen, sorry.

Aber was da geschrieben steht, ist mir durchaus bekannt und bewußt.
Ich habe leider noch vergessen zu erwähnen, daß bei jedem Homeverzeichnis auch das sog. "sticky bit" gesetzt ist. Das verhindert gerade eben im normalen Unix-Alltag, daß Dateien gelöscht werden können, die einem "nichts angehen" - auch wenn einem das Verzeichnis gehört.

Ich vermute schon eine ganze Weile, daß ProFTPD mit dem sticky bit nix anzufangen weiß. Trozdem wundert es mich, denn gleich nach dem Einloggen des Users gibt der gestartete ProFTPD-Prozess seine Root-Rechte auf und läuft unter der User- und Gruppen-ID des angemeldeten Users.

Da der Prozess dann keine Root-Rechte mehr hat (haben dürfte!), dürfte es auch nicht mehr möglich sein, fremde Dateien/Verzeichnisse zu löschen. In der Shell ist das zumindest nicht möglich.
Was läuft da schief?

Nochmals vielen Dank für die rasche Antwort!
Vielleicht weißt Du (oder jemand anderes) was da los ist und vielleicht sogar, wie man das in normale Bahnen lenken kann - vielen Dank!

mfg.
  VolGas

Wir benutzen zwar Debain Stable, nutzen aber nicht dessen Server-Software, sondern haben diese selbst compiliert. Damit haben wir aktuellere Software und selbst mehr Kontrolle.

So wurde unser proFTPD compiliert:

Code:

./configure \
--with-modules="mod_ifsession:mod_readme: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 \
\
CFLAGS="-O3 -fexpensive-optimizations" \
CXX=gcc CXXFLAGS="-O3 -felide-constructors -fexpensive-optimizations -fno-exceptions -fno-rtti"

Damit haben wir bislang nur gute Erfahrungen gemacht.

mfg.
  VolGas