mod_mysql Verständnisfrage

[hos_joker]

Hallo,

folgendes ist mein Endziel: Jeder Systemuser soll die Möglichkeit haben, "Unteruser" anzulegen, die jeweils nur auf bestimmte Unterverzeichnisse Zugriff haben sollen. Also im Prinzip eine Funktion, die viele Oberflächen (syscp etc.) realisieren. Diese Unteruser sollen mit der gleichen UID/GID wie der entsprechende Systemuser unterwegs sein, so dass Dateien beliebig änderbar sind.

Folgendermaßen habe ich es probiert: Systemuser loggen sich ganz normal über PAM ein, für die Unteruser wird mod_mysql benutzt. Diesen Usern gebe ich die gleiche UID/GID wie dem Systemuser (die hole ich aus /etc/passwd). <-- Bei dem Schritt bin ich mir nicht sicher, ob ein Verständnisproblem vorliegt, DENN: Der Unteruser kann sich zwar einloggen, hat dann aber nur World-Rechte und nicht Owner-Rechte

Ist das überhaupt so realisierbar? Oder muss ich vorhandene Systemuser erst umständlich in die DB einlesen? (wie ich es bei syscp gesehen habe)

[VolGas]

Hallo!

Prinzipiell kann man das wirklich so machen (ich bleibe einmal bei Deiner Terminologie):
Systemuser aus dem System holen und wenn der User dort nicht bekannt ist, Unteruser
in der SQL-DB nachsehen.

Besser (weil übersichtlicher und zuverlässiger) wäre es jedoch, wenn alle FTP-User in
SQL zusammen administriert würden. Gleich noch eines: die Benutzung der PAM für
den ProFTPD ist nicht nur nicht notwendig, sondern nur ein zusätzlicher Aufwand und
eine weitere mögliche Fehlerquelle.

Über "mod_sql" werden Username, Passwort, Home-Dir, UID/GID an den ProFTPD weiter-
gegeben, das funktioniert sehr einfach und zuverlässig. Wenn nicht, hast Du einen Fehler
in Deiner Konfiguration. Letztendlich dürfte -bei richtigen Daten in der SQl-DB- gar kein
Unterscheid bemerkbar sein ob System- oder "Unteruser". Nur die Reihenfolge der
Authorisation solltest Du mittels "AuthOrder mod_auth_unix.c mod_sql.c" definieren.

Wenn Du weiterhin Probleme haben solltest, dann poste Deine proftpd.conf hier.

mfg.
  VolGas

[hos_joker]

Ok - danke erstmal für deine Antwort...das macht je erstmal Hoffnung - dachte schon, das würde gar nicht funktionieren

Also - ich hab jetzt PAM deaktiviert udn AuthOrder gesetzt, gleiches Ergebnis. Login geht - hier mal die relevanten Konfigurationsdaten:

Code:

###############################################################################
#
# GENERAL CONFIGURATION
#
###############################################################################

AuthPAM                         off
User                            nobody
Group                           nobody
DefaultRoot                     /
Umask                           022
CommandBufferSize               255
DeferWelcome                    on
IdentLookups                    off
ListOptions                     "-a"
MaxClients                      40
MaxClientsPerHost               22
PassivePorts                    49152 65534
PathAllowFilter                 "^[a-zA-Z0-9öäüÖÄÜ \/_\.\+\-\:\,]+$"
PathDenyFilter                  "(\.ftp[a-z]+$)|(passwd.cdb)"
TimeoutIdle                     3600
TimeoutStalled                  3600
WtmpLog                         on
TimesGMT                        off
RequireValidShell               off

<Directory /*>
    HideUser                    root
    AllowOverwrite              on
</Directory>
AuthOrder mod_auth_unix.c mod_sql.c

###############################################################################
#
# MYSQL
#
###############################################################################
<IfModule "mod_sql.c">

  SQLConnectInfo                [db]@[server] [login] [pass]
  SQLLogFile                    /var/log/proftpd_sql.log
  SQLAuthTypes                  Crypt Plaintext
  SQLAuthenticate               users
  SQLUserInfo                   ftp_users username password uid gid homedir shell

  #allow only enabled users and users for this specific server
  SQLUserWhereClause            "login_enabled = 'Y' AND Server_Name = SUBSTRING_INDEX(USER(),'@',-1)"

  SQLLog PASS login
  SQLNamedQuery login UPDATE "last_login=now(), login_count=login_count+1 where username='%u'" ftp_users

  SQLLog RETR download
  SQLNamedQuery download UPDATE "down_count=down_count+1, down_bytes=down_bytes+%b where username='%u'" ftp_users

  SQLLog STOR upload
  SQLNamedQuery upload update "up_count=up_count+1, up_bytes=up_bytes+%b where username='%u'" ftp_users
</IfModule>

Jetzt das Anwendungsbeispiel:

Der Systemuser heißt foo und hat die UID/GID 750
Der "Unteruser": foo_0

Code:

id username uid gid password homedir        shell      login_enabled login_count last_login          up_count up_bytes down_count down_bytes Server_Name
1  foo_0    750 750 test1234 /usr/home/foo/ /bin/false Y             14          2006-09-20 15:51:16 0        0        0          0          server.name

Einloggen klappt wie gesagt. Aber beim Verzeichniswechsel:

Code:

Befehl: CWD temp
Antwort: 550 temp: Permission denied
Fehler: Dateiliste konnte nicht empfangen werden

Siehst du einen Fehler in der Konfiguration?

[VolGas]

Ja, mir ist das sofort ins Auge gesprungen: "DefaultRoot /"
Damit landen alle(!) User im Root-, nicht in Ihrem Homeverzeichnis und haben volle
Bewegungsfreiheit - solange die Zugriffsrechte dies zulassen. Und das tun sie wohl
nicht, was auch völlig in Ordnung ist.

"DefaultRoot ~" ist das Mittel der Wahl: es "beamt" jeden User in sein eigenes
Verzeichnis und "sperrt" ihn dann dort ein. (chroot)

Wenn es das nur war, dann können wir ja zufrieden sein, oder?

mfg.
  VolGas

[hos_joker]

Die DefaultRoot Geschichte hab ich mir nicht ausgedacht - es gibt wohl (leider) Gründe, warum das so gemacht wurde. Soweit ich mich erinnere, hat es was damit zu tun, dass die User Zugriff auf 2 Verzeichnisse haben sollen (ohne 2. Login). Gibt es da ne andere Möglichkeit?

Ansonsten habe ich das Problem beheben können (deine Beispiel-Konfig hat mich auf den richtigen Weg gebracht )

SQLMinUserUID 500
SQLMinUserGID 500

Diese Werte stehen standardmäßig auf 999/999 - und meine 750 aus dem Beispiel fallen da nicht rein...

[VolGas]

Schön, daß Dir meine Beispiel-Konfig weitergeholfen hat.

Aber das ist auch für mich etwas Neues, daß ohne explizite Angabe von "SQLMinUserUID"
oder "SQLMinUserGID" derartige Default-Restriktionen wirksam sind.

Ist dem so?
Ich möchte es an unseren laufenden Servern nicht ausprobieren...

Das Einloggen auf Root-Ebene finde ich persönlich Sch...
...recklich [Ähem!].
Es gibt noch die Lösung mit dem Unix-Befehl "mount --bind ..." ein Verzeichnis in einem
anderen zu mounten (siehe auch FAQ). Das verbraucht allerdings System-Resourcen und
will ordentlich gepflegt sein.

Du könntest auch die Direktive ->DefaultChdir nutzen, um die User in ihr HomeDir zu beamen,
aber der Schutz des "DefaultRoot" fehlt damit völlig: der User kann hin, wohin er auch möchte.
Eine weitere Alternative wäre der Einsatz der "VRootEngine" (mod_vroot), das nicht ganz so
restriktiv wie "DefaultRoot" ist und Symlinks, die nach außerhalb des "Gefängnisses"
verweisen, zuläßt. Mit z.B. PHP ist solch ein Symlink aber auch ganz einfach selbst gesetzt...

Alles in Allem würde ich nicht auf "DefaultRoot" verzichten wollen - die Sicherheit des
Servers ist mir zig-tausendfach wichtiger als vielleicht eine Bequemlichkeit für den User.
Schließlich ist das für den User auch sehr wichtig. (sollte es zumindest sein!)

Kleiner Nachtrag zu vorhin: das Feld "shell" bei "SQLUserInfo" ist ein Anachronismus und
bewirkt (meines Wissens) rein gar nichts - außer Platz belegen. Wenn Du dieses durch "NULL"
ersetzt, kannst Du Dir das Feld in der Datenbank sparen. Wenn z.B. auch die Gruppe immer
die selbe sein soll, kannst Du dort auch "NULL" hineinschreiben und "SQLDefaultGID" nutzen.
Die Seite mit den Direktiven (siehe ->hier) kann sehr inspirierend sein.

Funktioniert Deine Installation nun eigentlich?

mfg.
  VolGas

[stonki]

naja, es gibt noch die Möglichkeit von VROOT, und dann das andere Verzeichnis via ln -s einbinden.
http://www.castaglia.org/proftpd/modules/mod_vroot.html

[VolGas]

@stonki:

Das hatte ich schon erwähnt, hatte aber den Link dazu nicht zur Hand.
Danke!

Gruß
  V.

[hos_joker]

Danke - mod_vroot werde ich mir auf jeden Fall ansehen - war mit der bisherigen Lösung auch immer sehr unzufrieden.

Ansonsten läuft die Konfiguration jetzt wie vorgesehen, auch meine "Spezialwünsche" laufen hervorragend. Vielen Dank für die tolle Hilfe!

[VolGas]

Bitteschön!

Eines noch: vielleicht ist mit "mod_vroot " dann auch "ShowSymlinks off" interessant,
damit nicht jeder gleich den Symlink als solches erkennen kann. Damit wäre die Sicherheit
wieder etwas erhöht...

mfg.
  VolGas

[hos_joker]

Ich hab das mal probiert - in meinem FTP-Programm (Filezilla) sieht der Symlink jetzt komplett aus wie ein normales Verzeichnis! Wirklich erstaunlich - vom Handling her (also auch der angezeigte Pfad im FTP-Programm) sieht es aus, als wenn es keinen Symlink gäbe sondern nur ein ganz normales Verzeichnis...

Ich werd das mal weiter testen ob es nicht doch irgendeinen Fallstrick gibt...klingt ja fast zu gut um wahr zu sein

[VolGas]

 

Aber denke daran: der Fake funktioniert nur mit FTP.
Wenn jemand mit einem Script das Verzeichnis direkt ausliest oder gar Shell-Zugang hat,
sieht er natürlich alles, wie es wirklich ist.

mfg.
  VolGas

[hos_joker]

Wenn man die bisherige "Lösung" sieht, ist mod_vroot schon mal ein großer Sprung in die richtige Richtung. Eine Lösung per bind oder gar eine Änderung der Filesystemstruktur kommen im Moment leider nicht in Frage.