www.ProFTPD.de
13. März 2007, 19:19:37 *
Willkommen Gast. Bitte einloggen oder registrieren.
Haben Sie Ihre Aktivierungs E-Mail übersehen?

Einloggen mit Benutzername, Passwort und Sitzungslänge
News: SMF - Neu installiert!
 
   Übersicht   Hilfe Suche Login Registrieren  
Seiten: [1]   Nach unten
  Drucken  
Autor Thema: Update proftpd 1.2.x auf 1.3.0a Problem (Rechte)  (Gelesen 130 mal)
0 Mitglieder und 1 Gast betrachten dieses Thema.
uLtrA
ProFTPD
*
Offline Offline

Beiträge: 11


Profil anzeigen
« am: 12. Dezember 2006, 14:51:18 »

Hallo,

sorry das ich euch schon ein zweites mal innerhalb einer Woche störe Zwinkernd
Mein erstes Problem hat sich glücklicherweise dank Volgas gelöst, nun habe ich aber folgendes Problem, nachdem ich die neue Version compiliert habe, wollte ich einfach meine alte "config" übernehmen.
siehe:

Code:
  This is a basic ProFTPD configuration file (rename it to
# 'proftpd.conf' for actual use.  It establishes a single server
# and a single anonymous login.  It assumes that you have a user/group
# "nobody" and "ftp" for normal operation and anon.

serverName                      "xxxxsServer"
ServerType                      standalone
Defaultserver                   on

#Serveradmin                     admin@xxxxxxxxx.com
#SQLLOGFilE                      /var/log/proftpd.sql
RequireValidShell               off

# Port 21 is the standard FTP port.
Port                           21

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask                           022


# To prevent DoS attacks, set the maximum number of child processes
# to 30.  If you need to allow more than 30 concurrent connections
# at once, simply increase this value.  Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd).
MaxInstances                    30

User                            wwwrun
Group                           www

# To cause every FTP user to be "jailed" (chrooted) into their home
# directory, uncomment this line.
DefaultRoot ~

# Normally, we want files to be overwriteable.
<Directory />
  AllowOverwrite                on
</Directory>

# Beschräungen auf Upload fuer Fotografen
<Directory /xyz/html/photos/upload/*/*>
  <Limit ALL>
    AllowUser xxx
    AllowUser xxy
#    DenyAll
#  </Limit>
#  <Limit APPE STOR STOU CDUP CWD XCWD XCUP LIST>
    AllowAll
  </Limit>
</Directory>

# Beschräung, dass Fotografen in upload/ direkt nichts uppen duerfen
<Directory /xyz/html/photos/upload/*>
  <Limit ALL>
    AllowUser xxx
    AllowUser xxy
    AllowAll
#    DenyAll
  </Limit>
</Directory>


# Konfiguration
#neu
#AuthOrder mod_sql.c



SQLAuthTypes Plaintext
SQLAuthenticate users*
SQLConnectInfo proftpd@213.13.213.123 proftpd passwort
SQLDefaultGID                   8
SQLDefaultUID                   30



#MaxClientsPerHost 2 "Nicht mehr als %m Verbindungen"
MaxClients 10 "Leider sind schon %m Clients verbunden"
MaxLoginAttempts 3

SQLLog PASS updatecount
SQLNamedQuery updatecount UPDATE "count=count+1,letzer_zugriff=now()  WHERE userid='%u'" users

# xfer Log in mysql
SQLLog RETR,STOR transfer1
SQLNamedQuery  transfer1 INSERT "'%u', '%f', '%b', '%h', '%a', '%m', '%T',now(), 'c', NULL" xfer_stat

SQLLOG ERR_RETR,ERR_STOR transfer2
SQLNamedQuery  transfer2 INSERT "'%u', '%f', '%b', '%h', '%a', '%m', '%T',now(), 'i', NULL" xfer_stat


Das Problem ist ich habe den FTP nicht eingerichtet, das war mein Vorgänger, mit der alten Version funktioniert alles einwandfrei :/
Wenn ich jedoch die neue Version von proftpd nutze, bekomme ich Probleme mit der Berechtigung. Mir scheint es so als ob der User nicht wirklich "wwwrun" ist, obwohl der Dienst unter wwwrun im Top und ps auftaucht? Meine Verzeichnisse und Dateien sind alle wwwrun:www und der der ftp soll quasi derselbe User sein.
Wenn ich auf meinem FTP bin, komme ich dann nur noch in Unterverzeichnise die mind. drwxr-xr-x sind.
Auch Dateien lassen sich lesen, nur nicht alle, da manche Ordner z.b. nur
Code:
drwxr-x---   3 wwwrun www   4096 2006-02-01 18:23 mediendaten
sind.
Normal müsste das doch weiterhin so funktionieren, im Debug Modus habe ich nur was von SQLAuthMode entdeckt und Authorder etc.

Hier das Log beim starten:

Code:
- dispatching event 'core.module-load' to mod_sql_mysql
 - dispatching event 'core.module-load' to mod_sql_mysql
 - dispatching event 'core.preparse' to mod_sql
 - parsing '/usr/local/proftpd/1.3.0/etc/proftpd.conf' configuration
 - FS: using system open()
 - FS: using system read()
 - dispatching directive 'ServerName' to module mod_core
 - dispatching directive 'ServerType' to module mod_core
 - dispatching directive 'DefaultServer' to module mod_core
 - dispatching directive 'RequireValidShell' to module mod_auth
 - dispatching directive 'Port' to module mod_core
 - dispatching directive 'Umask' to module mod_core
 - FS: using system read()
 - dispatching directive 'MaxInstances' to module mod_core
 - dispatching directive 'User' to module mod_core
 - dispatching auth request "getpwnam" to module mod_sql
 - dispatching auth request "getpwnam" to module mod_auth_file
 - dispatching auth request "getpwnam" to module mod_auth_unix
 - retrieved UID 1001 for user 'wwwrun'
 - dispatching directive 'Group' to module mod_core
 - dispatching auth request "getgrnam" to module mod_sql
 - dispatching auth request "getgrnam" to module mod_auth_file
 - dispatching auth request "getgrnam" to module mod_auth_unix
 - retrieved GID 1001 for group 'www'
 - dispatching directive 'DefaultRoot' to module mod_auth
 - dispatching directive '<Directory>' to module mod_core
 - <Directory />: deferring resolution of path
 - dispatching directive 'AllowOverwrite' to module mod_xfer
 - dispatching directive '</Directory>' to module mod_core
 - dispatching directive '<Directory>' to module mod_core
 - <Directory /partyfans/html/photos/upload/*/*>: deferring resolution of path
 - dispatching directive '<Limit>' to module mod_core
 - dispatching directive 'AllowUser' to module mod_core
 - dispatching directive 'AllowUser' to module mod_core
 - dispatching directive 'AllowAll' to module mod_core
 - dispatching directive '</Limit>' to module mod_core
 - dispatching directive '</Directory>' to module mod_core
 - dispatching directive '<Directory>' to module mod_core
 - <Directory /partyfans/html/photos/upload/*>: deferring resolution of path
 - dispatching directive '<Limit>' to module mod_core
 - dispatching directive 'AllowUser' to module mod_core
 - dispatching directive 'AllowUser' to module mod_core
 - dispatching directive 'AllowAll' to module mod_core
 - dispatching directive '</Limit>' to module mod_core
 - dispatching directive '</Directory>' to module mod_core
 - dispatching directive 'SQLAuthTypes' to module mod_sql
 - dispatching directive 'SQLAuthenticate' to module mod_sql
 - SQLAuthenticate: use of * in SQLAuthenticate has been deprecated.  Use AuthOrder for setting authoritativeness
 - dispatching directive 'SQLConnectInfo' to module mod_sql
 - dispatching directive 'SQLDefaultGID' to module mod_sql
 - FS: using system read()
 - dispatching directive 'SQLDefaultUID' to module mod_sql
 - dispatching directive 'MaxClients' to module mod_auth
 - dispatching directive 'MaxLoginAttempts' to module mod_auth
 - dispatching directive 'SQLLog' to module mod_sql
 - dispatching directive 'SQLNamedQuery' to module mod_sql
 - dispatching directive 'SQLLog' to module mod_sql
 - dispatching directive 'SQLNamedQuery' to module mod_sql
 - dispatching directive 'SQLLog' to module mod_sql
 - dispatching directive 'SQLNamedQuery' to module mod_sql
 - FS: using system read()
 - FS: using system close()
 - attempting to resolve 'loveparade' to IPv4 address via DNS
 - resolved 'loveparade' to IPv4 address 127.0.0.1
loveparade -
loveparade - Config for XXXXXXXXXXXXXXXXXXX:
loveparade - /xyz/html/photos/upload/*
loveparade -  Limit
loveparade -   AllowUser
loveparade -   AllowUser
loveparade -   AllowAll
loveparade -  RequireValidShell
loveparade -  Umask
loveparade -  SQLAuthTypes
loveparade -  SQLAuthenticate
loveparade -  SQLConnectInfo
loveparade -  SQLDefaultGID
loveparade -  SQLDefaultUID
loveparade -  MaxClients
loveparade -  SQLLog_PASS
loveparade -  SQLNamedQuery_updatecount
loveparade -  SQLLog_RETR
loveparade -  SQLLog_STOR
loveparade -  SQLNamedQuery_transfer1
loveparade -  SQLLog_ERR_RETR
loveparade -  SQLLog_ERR_STOR
loveparade -  SQLNamedQuery_transfer2
loveparade - /xyz/html/photos/upload/*/*
loveparade -  Limit
loveparade -   AllowUser
loveparade -   AllowUser
loveparade -   AllowAll
loveparade -  RequireValidShell
loveparade -  Umask
loveparade -  SQLAuthTypes
loveparade -  SQLAuthenticate
loveparade -  SQLConnectInfo
loveparade -  SQLDefaultGID
loveparade -  SQLDefaultUID
loveparade -  MaxClients
loveparade -  SQLLog_PASS
loveparade -  SQLNamedQuery_updatecount
loveparade -  SQLLog_RETR
loveparade -  SQLLog_STOR
loveparade -  SQLNamedQuery_transfer1
loveparade -  SQLLog_ERR_RETR
loveparade -  SQLLog_ERR_STOR
loveparade -  SQLNamedQuery_transfer2
loveparade - /
loveparade -  AllowOverwrite
loveparade -  RequireValidShell
loveparade -  Umask
loveparade -  SQLAuthTypes
loveparade -  SQLAuthenticate
loveparade -  SQLConnectInfo
loveparade -  SQLDefaultGID
loveparade -  SQLDefaultUID
loveparade -  MaxClients
loveparade -  SQLLog_PASS
loveparade -  SQLNamedQuery_updatecount
loveparade -  SQLLog_RETR
loveparade -  SQLLog_STOR
loveparade -  SQLNamedQuery_transfer1
loveparade -  SQLLog_ERR_RETR
loveparade -  SQLLog_ERR_STOR
loveparade -  SQLNamedQuery_transfer2
loveparade - DefaultServer
loveparade - RequireValidShell
loveparade - Umask
loveparade - UserID
loveparade - UserName
loveparade - GroupID
loveparade - GroupName
loveparade - DefaultRoot
loveparade - SQLAuthTypes
loveparade - SQLAuthenticate
loveparade - SQLConnectInfo
loveparade - SQLDefaultGID
loveparade - SQLDefaultUID
loveparade - MaxClients
loveparade - MaxLoginAttempts
loveparade - SQLLog_PASS
loveparade - SQLNamedQuery_updatecount
loveparade - SQLLog_RETR
loveparade - SQLLog_STOR
loveparade - SQLNamedQuery_transfer1
loveparade - SQLLog_ERR_RETR
loveparade - SQLLog_ERR_STOR
loveparade - SQLNamedQuery_transfer2
loveparade - dispatching event 'core.postparse' to mod_delay
loveparade - ROOT PRIVS at mod_delay.c:292
loveparade - FS: using system open()
loveparade - RELINQUISH PRIVS at mod_delay.c:294
loveparade - FS: using system fstat()
loveparade - mod_delay/0.5: mapping DelayTable '/usr/local/proftpd/1.3.0/var/proftpd/proftpd.delay' into memory
loveparade - mod_delay/0.5: unmapping DelayTable '/usr/local/proftpd/1.3.0/var/proftpd/proftpd.delay' from memory
loveparade - FS: using system close()
loveparade - dispatching auth request "getgroups" to module mod_sql
loveparade - dispatching auth request "getgroups" to module mod_auth_file
loveparade - dispatching auth request "getgroups" to module mod_auth_unix
loveparade - retrieved group ID: 1001
loveparade - setting group ID: 1001
loveparade - SETUP PRIVS at main.c:2897
loveparade - ROOT PRIVS at main.c:1991
loveparade - RELINQUISH PRIVS at main.c:1998
loveparade - ROOT PRIVS at main.c:2346
loveparade - opening scoreboard '/usr/local/proftpd/1.3.0/var/proftpd/proftpd.scoreboard'
loveparade - RELINQUISH PRIVS at main.c:2372
loveparade - dispatching event 'core.startup' to mod_core
loveparade - ROOT PRIVS at inet.c:323
loveparade - RELINQUISH PRIVS at inet.c:381
loveparade - ProFTPD 1.3.0a (stable) (built Thu Nov 30 20:39:48 CET 2006) standalone mode STARTUP
loveparade - ROOT PRIVS at main.c:2209
loveparade - RELINQUISH PRIVS at main.c:2211
loveparade - FS: using system lstat()


Und hier das Log wenn ich in solch einen Ordner möchte:

Code:
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching PRE_CMD command 'NOOP' to mod_core
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching PRE_CMD command 'NOOP' to mod_core
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching CMD command 'NOOP' to mod_core
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching POST_CMD command 'NOOP' to mod_sql
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching LOG_CMD command 'NOOP' to mod_sql
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching LOG_CMD command 'NOOP' to mod_log
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching PRE_CMD command 'CWD /html/mediendaten/' to mod_core
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching PRE_CMD command 'CWD /html/mediendaten/' to mod_core
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching CMD command 'CWD /html/mediendaten/' to mod_core
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - in dir_check_full(): path = '/html/mediendaten', fullpath = '/xyz/html/mediendaten'.
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - FS: using system stat()
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - FS: using system stat()
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - FS: using system stat()
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - FS: using system stat()
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - FS: using system chdir()
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching POST_CMD_ERR command 'CWD /html/mediendaten/' to mod_sql
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching LOG_CMD_ERR command 'CWD /html/mediendaten/' to mod_sql
loveparade (p54AA5D03.dip.t-dialin.net[84.170.93.3]) - dispatching LOG_CMD_ERR command 'CWD /html/mediendaten/' to mod_log


Ich habe schon alles mögliche probiert, SQLDefaultGID, SQLDefaultUID auskommentiert, AuthOrder mod_sql.c reingeschrieben etc.


Ich komme leider nicht auf das Kernproblem, war mein proftpd nicht "wirklich" wwwrun gehört :S

Über Hilfe würde ich mich sehr freuen

danke & gruß
Jens
Gespeichert
VolGas
Moderator
ProFTPD
*****
Offline Offline

Beiträge: 771



Profil anzeigen
« Antwort #1 am: 13. Dezember 2006, 10:48:44 »

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
"SQLDefaultxxx"-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
« Letzte Änderung: 13. Dezember 2006, 10:55:20 von VolGas » Gespeichert
uLtrA
ProFTPD
*
Offline Offline

Beiträge: 11


Profil anzeigen
« Antwort #2 am: 13. Dezember 2006, 19:06:05 »

WoW Vielen Dank für die tolle Erklärung VolGas!

Es gibt eine gute und eine schlechte Nachricht Zwinkernd

a) Der Server läuft nachdem ich das mit dem SQLMinGID / UID gesetzt habe. (Das "lustige" ist, die SQLDefaultGID / UID war falsch (auf ein Debian Standard www-data gesetzt) normal dürfte der Server garnicht funktioniert haben?!? Es ging aber, zumindest schon seit knapp 2 Jahren ging das so..)

b) Wenn ich die Direktive: ... copy & paste
Code:
AuthOrder mod_sql.c



SQLAuthTypes Plaintext
SQLAuthenticate users
SQLConnectInfo proftpd@88.198.0.245 proftpd passwortpf
#SQLUserInfo                     users userid password NULL NULL homedir NULL
SQLMinUserUID                   2
SQLMinUserGID                   2
SQLDefaultUID                   1001
SQLDefaultGID                   1001

SQLUserInfo anschalte, sagt er mir im Debugmodus das er keine "Gruppe" kennt für mich als User.

Code:
loveparade (R2aad.r.pppool.de[89.54.42.173]) - ROOT PRIVS at main.c:1025
loveparade (R2aad.r.pppool.de[89.54.42.173]) - SETUP PRIVS at main.c:1030
loveparade (R2aad.r.pppool.de[89.54.42.173]) - FTP session requested from unknown class
loveparade (R2aad.r.pppool.de[89.54.42.173]) - performing module session initializations
loveparade (R2aad.r.pppool.de[89.54.42.173]) - mod_delay/0.5: opening DelayTable '/usr/local/proftpd/1.3.0/var/proftpd/proftpd.delay'
loveparade (R2aad.r.pppool.de[89.54.42.173]) - ROOT PRIVS at mod_delay.c:948
loveparade (R2aad.r.pppool.de[89.54.42.173]) - FS: using system open()
loveparade (R2aad.r.pppool.de[89.54.42.173]) - RELINQUISH PRIVS at mod_delay.c:950
loveparade (R2aad.r.pppool.de[89.54.42.173]) - ROOT PRIVS at mod_auth.c:145
loveparade (R2aad.r.pppool.de[89.54.42.173]) - opening scoreboard '/usr/local/proftpd/1.3.0/var/proftpd/proftpd.scoreboard'
loveparade (R2aad.r.pppool.de[89.54.42.173]) - RELINQUISH PRIVS at mod_auth.c:147
loveparade (R2aad.r.pppool.de[89.54.42.173]) - AuthOrder in effect, resetting auth module order
loveparade (R2aad.r.pppool.de[89.54.42.173]) - performing ident lookup
loveparade (R2aad.r.pppool.de[89.54.42.173]) - ident connection failed: Interrupted system call
loveparade (R2aad.r.pppool.de[89.54.42.173]) - ident lookup returned 'UNKNOWN'
loveparade (R2aad.r.pppool.de[89.54.42.173]) - connected - local  : 213.133.111.60:21
loveparade (R2aad.r.pppool.de[89.54.42.173]) - connected - remote : 89.54.42.173:1891
loveparade (R2aad.r.pppool.de[89.54.42.173]) - FTP session opened.
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching PRE_CMD command 'USER uLtrA' to mod_core
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching PRE_CMD command 'USER [sL]uLtrA' to mod_core
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching PRE_CMD command 'USER uLtrA' to mod_delay
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching PRE_CMD command 'USER uLtrA' to mod_auth
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching auth request "endpwent" to module mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching auth request "endgrent" to module mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching CMD command 'USER 'uLtrA' to mod_auth
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching auth request "getgroups" to module mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - no supplemental groups found for user 'uLtrA'
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching POST_CMD command 'USER uLtrA' to mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching POST_CMD command 'USER uLtrA' to mod_delay
loveparade (R2aad.r.pppool.de[89.54.42.173]) - mod_delay/0.5: mapping DelayTable '/usr/local/proftpd/1.3.0/var/proftpd/proftpd.delay' into memory
loveparade (R2aad.r.pppool.de[89.54.42.173]) - mod_delay/0.5: write-locking DelayTable '/usr/local/proftpd/1.3.0/var/proftpd/proftpd.delay', row 1
loveparade (R2aad.r.pppool.de[89.54.42.173]) - mod_delay/0.5: selecting median interval from 32 values
loveparade (R2aad.r.pppool.de[89.54.42.173]) - mod_delay/0.5: adding 173 usecs to USER row
loveparade (R2aad.r.pppool.de[89.54.42.173]) - mod_delay/0.5: unlocking DelayTable '/usr/local/proftpd/1.3.0/var/proftpd/proftpd.delay', row 1
loveparade (R2aad.r.pppool.de[89.54.42.173]) - mod_delay/0.5: unmapping DelayTable '/usr/local/proftpd/1.3.0/var/proftpd/proftpd.delay' from memory
loveparade (R2aad.r.pppool.de[89.54.42.173]) - mod_delay/0.5: additional random delay of 3 usecs added
loveparade (R2aad.r.pppool.de[89.54.42.173]) - mod_delay/0.5: delaying for 67 usecs
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching LOG_CMD command 'USER uLtrA' to mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching LOG_CMD command 'USER uLtrA' to mod_log
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_core
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_core
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching auth request "getgroups" to module mod_sql
[b]loveparade (R2aad.r.pppool.de[89.54.42.173]) - no supplemental groups found for user 'uLtrA'[/b]
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_delay
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching PRE_CMD command 'PASS (hidden)' to mod_auth
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching auth request "endpwent" to module mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching auth request "endgrent" to module mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching CMD command 'PASS (hidden)' to mod_auth
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching auth request "getpwnam" to module mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching event 'core.exit' to core
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching event 'core.exit' to mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching event 'core.exit' to mod_auth_unix
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching auth request "endpwent" to module mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching auth request "endgrent" to module mod_sql
loveparade (R2aad.r.pppool.de[89.54.42.173]) - dispatching event 'core.exit' to mod_xfer
loveparade (R2aad.r.pppool.de[89.54.42.173]) - FTP session closed.

Mein Tabellenlayout scheint auch ganz anders aus als ich es ja in der SQLUserInfo angebe. Im Prinzip hat das Layout
" userid        passwd        uid        gid        homedir        shell        letzer_zugriff        count"

Wenn ich das aber ohne "users" am Anfang schreibe sondern nur "userid password NULL NULL homedir NULL" schreibe startet mein proftpd nicht.
die NULL's sollen ja jeweils für UID, GID, Shell stehen.


Naja ich habe halt nun SQLUserInfo auskommentiert, da funktioniert es, ich schätze mal immer noch sicherer als auf 1.2.x Version zu bleiben Smiley Leider mache ich das nur nebenbei hobbymässig und habe nicht soooviel Zeit, gibt leider viele andere Dinge die ich dringenst machen muss.
Deshalb bin ich jetzt zufrieden das es so funktioniert.
Oder würdest du mir aus Sicherheitsgründen abraten, das so weiter zu betreiben?

Sonst werde ich mir wohl in den Weihnachtsferien die Zeit nehmen und eine komplett neue Konfiguration schreiben, unsere ist halt einfach "murks" Zunge


Ich danke dir aufjedenfall für die nette Unterstützung!


gruß Jens
Gespeichert
VolGas
Moderator
ProFTPD
*****
Offline Offline

Beiträge: 771



Profil anzeigen
« Antwort #3 am: 14. Dezember 2006, 07:21:57 »

Bitteschön!

Die Beschreibung der Parameter von "SQLUserInfo" ist auf Stonki's Website ist leider nicht ganz mit
der Syntax indentisch. Das liegt wohl daran, daß auf der "offiziellen" ProFTPD-Website die Doku arg
zusammengestückelt ist und noch jenseits von gut und böse ist. Erst auf der Entwicklersite ist eine
brauchbare Doku für die Direktive zu finden - und tatsächlich: es gibt für "SQLUserInfo" einen Default-
Wert: "users userid passwd uid gid homedir shell"

Der erste Parameter gibt den Namen der Tabelle an, in dem sich die FTP-Userdaten befinden. Den
kann man natürlich nicht einfach weglassen oder ändern, sondern er muß schon den richtigen Namen
der SQL-Tabelle haben - auf Deinem Server heißt die Tabelle also wirklich "users". Wie das Tabellen-
layout tatsächlich aussieht, spielt für "mod_sql" eigentlich keine Rolle, dafür bekommt es ja via
"SQLUserInfo" die Feldnamen mitgeteilt, die es abfragen soll. Der "Rest" der Tabelle sowie die
"NULL"-Felder sind für "mod_sql" irrelevant und werden nicht weiter beachtet.

Ich würde vorschlagen, daß Du "SQLUserInfo" wieder aktivierst - ist sicherer und sauberer.
Daß der ProFTPD im Debugmodus ein bischen meckert, ist nicht weiter schlimm. Das liegt daran,
daß keine Gruppen via "SQLAuthenticate" aktiviert und mit "SQLGroupInfo" definiert wurden.
Das braucht man in der Regel auch nicht und kann es getrost weglassen. Eigentlich kann man auch
nicht von Meckern reden, es ist nur eine Feststellung, eine Bemerkung.

Die Werte von "SQLMinUserUID" & "SQLMinUserGID" auf solch niedrige Werte zu setzen, ist, mit
Verlaub, eine blöde Idee - auch wenn dies durch die nachfolgenden Direktiven eigentlich egal wäre.
Oft ändert man später etwas und dann sind solch vergessene "Sünden" echte Sicherheitslöcher.

Tipp: ein klein wenig kann man das SQL-Handling mit "SQLNegativeCache on" optimieren...

Zum Thema Konfiguration kann ich nur das Credo eines jeden erfahrenen System-Admins rezitieren:

  • If it's not broken - don't fix it!
  • Never touch a running system!
  • One backup a day keeps trouble away...

Bestimmt fällt Dir für die Feiertage doch etwas viel besseres ein, als Server zu konfigurieren -
hoff' ich doch...!

mfg.
  VolGas
« Letzte Änderung: 14. Dezember 2006, 07:40:28 von VolGas » Gespeichert
uLtrA
ProFTPD
*
Offline Offline

Beiträge: 11


Profil anzeigen
« Antwort #4 am: 14. Dezember 2006, 13:11:17 »

Danke auch hierbei wieder Smiley

Das minUID/GID habe ich auch wieder auskommentiert, da der Server ja über 1000 läuft.
Um die SQLUserInfo kümmere ich mich dann heute Abend nochmal

Sicher fällt mir über die Feiertage was besseres ein ;-)

Falls man sich nichtmehr schreibt, schonmal schöne Feiertage!
Gespeichert
Seiten: [1]   Nach oben
  Drucken  
 
Gehe zu:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Prüfe XHTML 1.0 Prüfe CSS
Seite erstellt in 0.073 Sekunden mit 16 Zugriffen.