Rechteproblem ProFTP vs. Webspace

[siradlib]

Hallo,

ich bin langsam ratlos: Ich möchte/muss einen FTP-User einrichten, der auf ein Verzeichnis unterhalb des Apache-Document-Root zugreifen soll, ein Download-Verzeichnis.
Mein erster Versuch war, einen ganz normalen Plesk-Web-User anzulegen, und dessen Homeverzeichnis mit "mount --bind" in den Webspace zu spiegeln. Leider gibt es zur Option "--bind" von mount keine Möglichkeit, die UID und GID des Users im Zielverzeichnis/Mountpoint zu manipulieren, so dass ich mit Rechteproblemen aufgab.
Problem: Eine Extension von Typo3 zeigt nur dann die Dateien an, wenn die UID der Dateien dies des normalen Webspace-FTP ist. (Ich habe FastCGI mit getrennten Usern pro Webspace laufen.)
Ein (lokaler) Export und Remount des Verzeichnisses per NFS scheitert ebenfalls daran, dass ich beim Dateisystem nfs keine UID und GID für das Zielverzeichnis angeben kann.

Was gäbe es jetzt noch für Optionen?
Ich hätte gerne, dass ProFTP

1. in ein Verzeichnis unterhalb des DocumentRoot wechseln darf
2. und die dort abgelegten Dateien dem normalen FTP-Benutzer des Webspace gehören, dieser Benutzer aber trotzdem nicht das komplette Documentroot überschreiben darf

Meine Idee war jetzt:
1. Gebe dem FTP-User eine spezielle Gruppe
2. In der /etc/proftpd.conf diese spezielle Gruppe "hyladlftp" vom Defaultroot auszunehmen:

<Global>
DefaultRoot     ~               psacln,!hyladlftp
AllowOverwrite          on
</Global>

Das Anmelden schlägt trotzdem fehl und in /var/log/messages finde ich ein:

hxxxxxx proftpd[7303]: hXXXXXX.stratoserver.net (78.xx.246.xxx[78.xx.246.xxx]) - prdownload chdir("/var/www/vhosts/mydom.net/httpdocs/mydownload/prdownload"): Permission denied

Dem Verzeichnis "prdownload" habe ich testweise mal die Rechte 777 gegeben, aber selbst das funktioniert nicht- ich vermute, weil eben der "prdownload"-Benutzer im DocumentRoot weiter oben ja keine Rechte hat. Oder?


Hat jemand eine Idee?

 

[tekknokrat]

Ich bin zwar kein Pleskuser und kann dir mit speziellen Plesktips&tricks auch nicht dienen. Aber wie wäre es wenn Du das Homeverzeichnis dieses speziellen Users, der nur in diesen speziellen Ordner schreiben soll, auf den Ordnerpfad setzt.
Dann Berechtigung anpassen und gut?!

 

[siradlib]

Aber wie wäre es wenn Du das Homeverzeichnis dieses speziellen Users, der nur in diesen speziellen Ordner schreiben soll, auf den Ordnerpfad setzt.
Dann Berechtigung anpassen und gut?!

Diese Idee hatte ich auch schon.

Probleme hierbei waren dann:
- kollidierte mit den chroot-Einstellungen von proFTPd, und als ich diesen speziellen Ordner als Default-Chroot für diesen ftp-User gesetzt hatte, gab es o.g. Fehlermeldung (permission denied, siehe Ausschnitt aus der /var/log/messages oben)
- die neu per FTP heraufgeladenen Dateien hätten doch als Besitzer die UID des hochladenden FTP-Users und nicht des Webspace-Users

ratlose Grüße, trotzdem natürlich vielen Dank!!
siradlib

 

[siradlib]

Problem gelöst!

Ich habe dem FTP-Download-User mittels "vipw" die UID und GID des Web-FTP-Benutzers zugewiesen und als Home-Directory das "Download-Verzeichnis" zugewiesen (ebenfalls mit vipw).
Ich habe also einen "Alias" des Web-FTP-Benutzers erzeugt, mit anderem Benutzernamen und anderem Passwort.

Da der FTP-Download-User Dank des Chroot von proFTPd sein Homedirectory nicht verlassen darf, sollte das auch keine Sicherheitslücken aufreißen.

Oder mache ich einen Denkfehler, was die Sicherheit angeht?

 

[tekknokrat]

Hi,

zu meinem Verständnis es gibt mind. 2 Arten von chroot. Einmal den Server direkt in eine chroot Umgebung zu konfigurieren, ist das bei dir der Fall? Die andere Variante führt ja der FTP Server selber durch - nämlich bei Anmeldung des Benutzers ab in sein homedir.

Meine Shared Hosting (Standard syscp btw.) sieht so aus dass die Nutzer direkt per nss/pam authentifiziert werden und dann halt auch automatisch in ihrem Home landen. Für die Berechtigungen müssen die proftpd Einstellungen noch angepasst werden, wie spezielle Alias User/Group oder mask g+w...

Gegen ein alias Mapping mit einem Fremdtool (vipw) ist erstmal nichts einzuwenden so lange es restriktiv konfiguriert ist, klingt mir aber irgendwie alles zu kompliziert...

 

[d4f]

Meine Shared Hosting (Standard syscp btw.) sieht so aus dass die Nutzer direkt per nss/pam authentifiziert werden und dann halt auch automatisch in ihrem Home landen.

Syscp benutzt eine Datenbank wo es mehrere Aliases dem gleichen Benutzerkonto zuordnet mit jeweils unterschiedlichen chroot-Ordnern.
Das ist auch so ziemlich die sauberste moegliche Loesung



Eine sehr billige Loesung waere die Kombination aus Cronjob mit testdir und chown

 

[siradlib]

Ich meinte bei chroot in meinem Fall das chrooten, welches proFTPd macht, also dass proFTPd seine User in ihre jeweiligen $HOMEs einsperrt.

Syscp benutzt eine Datenbank wo es mehrere Aliases dem gleichen Benutzerkonto zuordnet mit jeweils unterschiedlichen chroot-Ordnern.
Das ist auch so ziemlich die sauberste moegliche Loesung

Heißt das, Syscp macht es genauso wie ich? Richtig verstanden?

Zur Veranschaulichung, meine /etc/passwd sieht ähnlich der folgenden aus:

domainftp:x:101:4711::/var/www/vhosts/domainftp:/bin/false
...
...
alias1:x:101:4711::/var/www/vhosts/domainftp/httpdocs/files/alias1files:/bin/false
alias2:x:101:4711::/var/www/vhosts/domainftp/httpdocs/files/alias2files:/bin/false
...

Ich habe also einen FTP-User "domainftp", dieser darf ins Verzeichnis der Domain "domain" schreiben, also nach /var/www/vhosts/domainftp.
Jetzt habe ich zwei zusätzliche User (alias1, alias2) angelegt, die ebenfalls in das zur Domain "domain" gehörende Verzeichnis schreiben dürfen, allerdings nur weiter unten im Verzeichnisbaum, nämlich in ihr jeweiliges Homeverzeichnis. Weiter nach oben im Verzeichnisbaum können sie nicht/sollten sie nicht können, das verhindert proFTPd durch sein chroot.

siradlib