Hallo!
Mache Dir keine Gedanken, von "stören" kann man hier nicht reden: es wird ja niemand gezwungen...
Schön, daß ich Dir bei Deinem vorherigen Problem helfen konnte und es nun funktioniert.
Prinzipiell ist zu sagen, daß in der Regel die proftpd.conf (außer bei Major-Releases) immer belassen
werden kann, wie sie ist und auch immer das selbe Verhalten des ProFTPD definieren. Die Zugriffsrechte
werden nicht vom ProFTPD definiert, sondern vom System. Der ProFTPD hat gar keine Möglichkeit, diese
zu umgehen oder abzuändern, da er wie eine Usershell zu sehen ist:
Vor dem Einloggen hat der für den einloggenden User individuell neu gestartete Prozess aus Sicherheits-
gründen die in der proftpd.conf mit den Direktiven
"User" und
"Group" definierten Rechte - genauso wie
der "Parent". Nach dem Einloggen wird der Prozess ganz kurz zum "root", nur um damit endgültig die
vordefinierten User- und Group-ID des eingeloggten Users anzunehmen und damit alle Root-Rechte zu
verlieren. Daraus folgt aber auch: der ProFTPD muß immer mit Root-Rechten gestartet werden, da nur
der Root-User User- und Group-ID wechseln kann!
Die User- und Group-ID, die Du mit dem Shell-Befehl "ps" siehst, sind in der Regel die, die für diesen
User definiert wurden. Das hat sich auch nicht durch das neu Compilieren des ProFTPD geändert: wenn
es jetzt nicht richtig funktionieren sollte, kann es vorher auch schon nicht richtig funktioniert haben.
Das Sternchen bei
"SQLAuthenticate users*" hat seine Bedeutung verloren und benötigt nun statt dessen
die Direktive
"AuthOrder mod_sql.c", um das selbe zu erreichen. Das ist wichtig, damit man nicht plötzlich
auch Systemuser mit anderen Settings für das FTP zulässt. Diese Direktive also bitte setzen, nicht aus-
kommentieren!
Deiner hier geposteten Konfiguration fehlt die Direktive ->
SQLUserInfo - deshalb wundert es mich, daß
Deine Konfiguration überhaupt funktioniert. Für alle Daten, die immer gleich bleiben und die nicht aus der
Datenbank geholt werden sollen, kann man bei dieser Direktive immer "NULL" setzen und dafür eine
"SQLDefault
xxx"-Direktive als Ersatz benutzen. Beispiel dafür wäre ->
SQLDefaultGID, wenn alle User
der selben Gruppe angehören sollen. Den Parameter "shell" von
"SQLUserInfo" kann man übrigens immer
als "NULL" definieren - dieses nutzlose Relikt muß man nicht auch noch pflegen...
Was noch zu beachten wäre: sind Deine User- und Gruppen-ID's (UID & GID) kleiner als 1000, so ist dies
mit
SQLMinUserUID und/oder
SQLMinUserGID unbedingt zu "legalisieren", sonst bleibt der Prozess
Eigentümer des vordefinierten Users und der Gruppe.
Jetzt habe ich fast schon eine ganze Abhandlung geschrieben, setzte das erst einmal um - dann sehen wir
evtl. weiter. Es sollte eigentlich zur Lösung des Problems (dicke!) reichen. Emfehlenswert sind auch die
SQL-Dokumentationen auf Stonki's Website unter dem Menüpunkt ->
Docs; hilfreich vielleicht auch diese
->
Beispielkonfiguration.
Viel Erfolg!
mfg.
VolGas