Erfahrungen apache2 mit PHP 5 als FastCGI

[Pawel]

Code: Alles auswählen

Connection refused: mod_fcgid: can't connect unix domain socket

AFAIR ist die Ursache für diesen Fehler die Stable Version von fcgid. Ein Update auf Testing (Etch) hilft da sehr. Auch sind einige (teilweise) nervige Bugs weniger drin.

[Kase]

Poste doch bitte mal deine suexec.log

[Zonk]

AFAIR ist die Ursache für diesen Fehler die Stable Version von fcgid. Ein Update auf Testing (Etch) hilft da sehr.

Das ist ja mal ein Ansatz:). Hatte schon dne apache im Verdacht.. werd ich heute gleich mal ausprobieren!! evtl klappts dann ja doch *g* *freu*


wie muss ich mein Debian Sarge konfigurierenn, dass er das Paket als Testing nimmt, ohne dass ihc mir da was zerschiesse? Besonders im Hinblick auf Updates?

Grüße Zonk

[Pawel]

wie muss ich mein Debian Sarge konfigurierenn, dass er das Paket als Testing nimmt, ohne dass ihc mir da was zerschiesse? Besonders im Hinblick auf Updates?

Das wurde schon besprochen, siehe folgendes oder hier steht, wie man die Sourcen aus dem Unstable Zweig bekommt. Vorsicht, beim letzteren stellt man als Default-Release "testing" ein.

[cirox]

läuft das "libapache2-mod-fcgid (1:1.10-2)" aktuell in TESTING (ETCH) auch mit Apache 2.0 in SARGE? Weil laut http://packages.debian.org/testing/net/ ... -mod-fcgid hängt es ja von Apache2.2 ab.

gruß cirox

[cirox]

also das Paket hängt vom Apache2.2 ab. Egal auf welcher Art man das nun einbauen möchte er möchte den Apache updaten unter Sarge. Bleibt also nur ein Selbstkompilieren, was aber bestimmt nicht Sinn der Sache ist.

Aber mal so einfach den Apache updaten ist natürlich auch so ne Sache. .....

[Kase]

Also ich bin mir recht sicher, dass fcgid auch mit Apache 2 funktioniert, vor allem, weil das Paket in unstable alles andere als neu ist (wegen Etch Release, in unstable 1.10 Juli 2006, aktuell ist 2.1 Feb 2007).

Zur Not einfach Mal von Hand die Abhängigkeit auf Apache2 verändern und auf die aktuelle in Sarge setzen (in debian/control) und probieren, ob Fehler kommen beim buildpackage.

Die entsprechenden Links zum Bauen von Paketen aus Testing oder Unstable hat Pawel ja bereits gepostet.

@Zonk:

Poste bitte nochmal die Rechte deines php-fcgi-starter und die Rechte des Verzeichnisses, in dem er liegt.

Code: Alles auswählen

ls -la  /var/www/default/conf/php-fcgi-starter

[cirox]

ja lieber am .deb rumpfriepeln , als dass system sarge mit apache2.2 zerschiessen?

Also, die Build-Depends sind: debhelper (>= 4.0.0), apache2-threaded-dev (>= 2.2.3-2), libtool, cdbs, libapr1-dev, pkg-config
Und die Depends: apache2.2-common

Klar die Depends geändert in: apache2-common
Und bei den Build-Depends: debhelper (>= 4.0.0), apache2-threaded-dev (>= 2.2.3-2), libtool, cdbs, libapr0-dev, pkg-config

und jetzt kommen die Fragen:

Also cdbs, apache2-threaded-dev, debhelper, libtool und pkg-config kann man unter sarge ja installieren, aber:

libapr1-dev muss zu libapr0-dev

Ich denke mal das ist besser als die libapr1-dev wieder aus TESTING zu holen, weil dann fängt ja das System zerschiessen schon wieder an ?

Auf jeden Fall bekommt man so erstmal das .deb Paket gebaut. Aber im Changelog steht:

Code: Alles auswählen

libapache2-mod-fcgid (1.10-1.1~smcv0) unstable; urgency=low

  * Non-maintainer upload.
  * Compile against Apache 2.2 and APR 1.0 (Closes: #391757, #393020).

Das gibt mir schon wieder zu denken wegen dem Compile against Apache 2.2 and APR 1.0 weil genau die Sachen hab ich ja siehe oben rausgeschmissen .....

[Kase]

In so einem Fall geht nur probieren und testen.

Wenn das Paket mit buildpackage gebaut werden kann, dann ist das schon mal viel Wert.

Installier das fertige Paket, du kannst dir damit ja quasi nichts kaputt machen, zur Not haust du es mit Purge einfach wieder runter.

mod_fcgid hat ja quasi keine Abhängigkeiten, und die Dateien sind auch sehr übersichtlich...

http://packages.debian.org/cgi-bin/sear ... &arch=i386

[Svenny]

Halli Hallo,

ich hab mir nun diesen Thread glaub ich 5 mal durchgelesen und am Ende ist nun doch eine Frage offen geblieben.

-> Ist es überhaupt Möglich phpX mit mod_fcgid in Sarge zu nutzen ohne an den debs rumzuschrauben oder selbst zu kompilieren?

Danekschön,
Sven

[Kase]

Ja, in Debian Sarge ist php-fcgi sowohl mit mod_fcgid als auch mit mod_fastcgi nutzbar.

Ich vermute bei Zonk auch eher ein Rechteproblem, denn der Apache legt den Socket an, ohne zu wissen, ob der PHP Prozess von suexec gestartet werden kann, oder nicht. Wenn der PHP Prozess nicht startet, schlägt natürlich das READ auf den Socket fehl, mit genau oben geposteter Fehlermeldung.

Aber so lange man weder die Rechte des fcgi-starters noch die suexec.log postet, kann man nun mal schlecht helfen.

[Svenny]

Das klingt ja schonmal aufmuntert. Wenn man sich den Thread so durchließt heißt es immer geht, geht nicht, geht, geht nicht, geht, geht nicht

Dann probier ich mal mein glück.

EDIT1: gehe ich nun recht in der annahme, dass php files immer executeable gechmodd'ed werden müssen?
EDIT2: Bei mir läufts leider auch nicht, hab den Apache grade gepurged und logischerweise alle Logfiles weg.
Auf jeden fall hatte das fcgi php script +x rechte und owner www-data (200) sowie sämtliche uid/gid ab /var/www aufwärts waren www-data(200):www-data(200)

das letzte was ich noch in meiner ssh session hab is die suexec.log mit

Code: Alles auswählen

[2007-03-08 03:50:57]: uid: (200/www-data) gid: (200/200) cmd: php.php
[2007-03-08 03:50:57]: (8)Exec format error: exec failed (php.php)

und die error.log:

Code: Alles auswählen

[Thu Mar 08 03:49:24 2007] [notice] mod_fcgid: server /var/www/php.php(7520) started
[Thu Mar 08 03:49:24 2007] [notice] mod_fcgid: server /var/www/php.php(7521) started
[Thu Mar 08 03:49:24 2007] [notice] mod_fcgid: server /var/www/php.php(7522) started
[Thu Mar 08 03:49:24 2007] [notice] mod_fcgid: server /var/www/php.php(7523) started
[Thu Mar 08 03:49:24 2007] [notice] mod_fcgid: server /var/www/php.php(7524) started
[Thu Mar 08 03:49:24 2007] [error] [client 84.129.108.135] Premature end of script headers: php.php
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: server /var/www/php.php(7525) started
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: process /var/www/php.php(7524) exit(communication error), terminated by calling exit(), return code: 255
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: process /var/www/php.php(7523) exit(server exited), terminated by calling exit(), return code: 255
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: process /var/www/php.php(7522) exit(server exited), terminated by calling exit(), return code: 255
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: process /var/www/php.php(7521) exit(server exited), terminated by calling exit(), return code: 255
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: process /var/www/php.php(7520) exit(server exited), terminated by calling exit(), return code: 255
[Thu Mar 08 03:49:34 2007] [notice] mod_fcgid: process /var/www/php.php(7525) exit(server exited), terminated by calling exit(), return code: 255

das wars.. sämtliche rechte hab ich auf www-data:www-data geänder /var/lib/apache2 und aufwärts..
das wrapper script sieht so aus:

Code: Alles auswählen

#!/bin/sh
PHPRC="/etc/php4/cgi/"
export PHPRC
PHP_FCGI_CHILDREN=10
export PHP_FCGI_CHILDREN
exec /usr/bin/php4-cgi

mehr input hab ich grade nicht und mein kopf sagt grade SEGFAULT und will ins bett. Also Gute nacht.

[Zonk]

Pardon, hatte grad Klausurenstress, weshalb ihc an dem Thema nchit weitergearbeite habe. Am Wochenende melde ich mich mit den neuesten Erkenntnissen.

Danke Zonk

[cirox]

Ja, in Debian Sarge ist php-fcgi sowohl mit mod_fcgid als auch mit mod_fastcgi nutzbar.

naja wenn man die Standardpakete nimmt in Sarge. Dort ist aber a) mod_fastcgi fehlerhaft (es kommt zu 500 Fehlern unter Last + noch ein paar andere Tücken ) und b) mod_fcgid liegt in einer ziemlich alten Version vor -> in den neueren wurden viel Bugfixes gemacht.

Des Weiteren ist in Sarge das neue mod_fcgid nicht nutzbar ( aus TESTING) ohne an den Abhängigkeiten rumzuschrauben, wenn man es nicht selbst kompiliert, da hier unter Debian der Apache 2.2 verlangt wird.

Ein Update auf Apache2.2 unter Sarge ist mir persönlich um Produktivbetrieb zu riskant, da noch nicht ausprobiert.

[Kase]

@Svenny:

Da ist noch was grundlegendes faul, poste mal bitte deine Configs:

fcgid.conf und dein vHost (fcgid.conf ganz und vhost mindestens die Zeilen SuexecUserGroup ... und FCGIWrapper ...)

Es ist sehr merkwürdig, warum er da "php.php" ausführen will, normalerweise sollte da der Name deines php-fcgi-starters stehen.

PHP Dateien müssen natürlich nicht ausführbar sein. Das, was ausführbar sein muss, ist der php-fcgi-starter.

[cirox]

@ kase Du bist genial Von Ihm stammen eigenlich alle Vorgehensweisen.

Verwendung von libapache2-mod-fcgid_1.10-2 unter sarge mit Apache 2.0.54. Zwischen den PHP Versionen kann mithilfe einer .htaccess Datei umgeschaltet werden.

zuerst nach dieser Anleitung das Paket nach sarge holen.

Bevor wir

Code: Alles auswählen

dpkg-buildpackage 

ausführen ändern wir die Abhängigkeite unter libapache2-mod-fcgid-1.10/debian/control:

Code: Alles auswählen

Build-Depends: debhelper (>= 4.0.0), apache2-threaded-dev, libtool, cdbs, libapr0-dev, pkg-config
Depends: apache2-common

danach:

Code: Alles auswählen

dpkg-buildpackage
cd ..
dpkg -i libapache2-mod-fcgid-1.10_i386.deb 

Fehlende Pakete per apt-get installieren.

Jetzt noch ein:

Code: Alles auswählen

for mod in fcgid; do a2enmod $mod; done

und das Modul ist aktiviert.

Danach wird genau so wie im Debianhowto verfahren. Mit dem "i" Bit und dem Starter.

Suexec ist aktiviert und wird auch so in den VHOST geschrieben:

Code: Alles auswählen

SuexecUserGroup VHOST_user VHOST_group

Die 2 Starter für beide PHP Versionen liegen unter "/var/www/php-fcgi-scripts/VHOST/" einmal der php-cgi-starter und der php4-cgi-starter.

Der Inhalt könnte so aussehen:

Code: Alles auswählen

#!/bin/sh
PHPRC="/etc/apache2/ini/VHOST/php5"
export PHPRC
PHP_FCGI_CHILDREN=2
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec /pfad/zum/php5-binary/php

und

Code: Alles auswählen

#!/bin/sh
PHPRC="/etc/apache2/ini/VHOST/php4"
export PHPRC
PHP_FCGI_CHILDREN=2
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec /pfad/zum/php4-binary/php

Wir verzichten auf die "FCGIWrapper" Angabe sondern gehen nach dem Debianhowto den Weg:

fcgi.conf:

Code: Alles auswählen

 SocketPath /var/lib/apache2/fcgid/sock
 IPCConnectTimeout 20
AddHandler php-fastcgi .php
AddHandler php4-fastcgi .php4
<Location /fcgi/php-fcgi-starter>
        SetHandler fcgid-script
        Options +ExecCGI
</Location>
<Location /fcgi/php4-fcgi-starter>
        SetHandler fcgid-script
        Options +ExecCGI
</Location>
Action php-fastcgi /fcgi/php-fcgi-starter
Action php4-fastcgi /fcgi/php4-fcgi-starter
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php4

In den VHOST kommt folgendes rein:

Code: Alles auswählen

ScriptAlias /fcgi/ /var/www/php-fcgi-scripts/VHOST/
        <Directory "/var/www/php-fcgi-scripts/VHOST">
                AllowOverride None
                Options +ExecCGI -MultiViews -Indexes
                Order allow,deny
                Allow from all
        </Directory>
AddHandler php4-fastcgi .php4
AddHandler php-fastcgi .php

danach noch:

Code: Alles auswählen

/etc/init.d/apache2 restart

Jetzt gehen erstmal alle .php Datein durch PHP5 und alle .php4 Dateien durch PHP4

Wenn wir über eine .htaccess Datei auf PHP4 schalten wollen muss folgendes in dieser hinzugefügt werden:

Code: Alles auswählen

AddHandler php4-fastcgi .php

PS: Wenn einer eine Lösung hat mit der Anweisung FCGIWrapper dann bitte posten, da in der neuesten fcgi Version direkt Direktiven innerhalb dieses Wrappers angewandt werden können.

[Kase]

Du solltest noch erwähnen, dass die Zeile:

Code: Alles auswählen

echo "APT::Default-Release \"testing\";" >> /etc/apt/apt.conf.d/70debconf

für Debian Sarge unbedingt:

Code: Alles auswählen

echo "APT::Default-Release \"stable\";" >> /etc/apt/apt.conf.d/70debconf

heißen sollte, sonst setzt man das falsche Default-Release

[Zonk]

ok ich habe jetzt folgen können und habe es am laufen mit fcgid..

das php file wird auhcschön angezeg ,aber nu nsteh ich wieder an der genau gleiche symphtomaik wie am anfang.. alleswird brav ausgeführ,t auhcwenn suexec einschriten sollete - es aber NICHT tut...

und das suexec logfile schweigt......


ihcwerd jetzt mal ein ganz neues debian aufsetzen

[Kase]

Was willst du denn bei suexec groß einrichten?

mod_fcgid hat eine integrierte suexec Steuerung, das einzigste, was du im vHost setzen musst, ist SuexecUserGroup user group.

[Zonk]

Ja Das frage ich mich auch... mich wundert halt serh was der Suexec macht..


meine erwartung an suexec:
es wechslt den user, und wenn das PHP-File was ausgeführt werdne soll, nicht dem SuexecUserGroup-Usergehört, gibt er eine Mismatch-Fehlermedung aus und bricht ab, selbst wenn der eigentliche Besitzer der Datei so offen war und sie mit den Rechten 777 ausgestattet hat..

Das was passiert:
Suexec/PHP führt die Datei fröhlich aus, egal was passiert, nur wenn sie dem Falschen gehört und auf 700 gestellt ist, kann er sie nicht ausführen... aber von Mismach-Warnungen und Abbruch keine Spur...

ich meine keiner bricht in eine Maschine ein, um seine Schadecode-Files dann freiwillig auf 700 zu begrenzen.....



bin ich etwa auf dme holzweg?

Danke für die hilfe, Zonk

[Kase]

Also mal nach der Reihe

Du benutzt mod_fcgid, oder benutzt du mod_fastcgi?

Falls mod_fcgid, poste mal bitte deine fcgid.conf und die Config eines kompletten vHost.

Außerdem wäre die error.log des Apachen interessant, wo man sieht, dass die php-fcgi Prozesse starten.

Edit: Außerdem bitte die Ausgabe von "a2enmod fcgid suexec"

[Zonk]

ok:)


also ich nutze mod_fcgid
php habe ich selberkompiliert.
PHP seiten werdne wie gewünscht ausgeführ,t abernicht durch suexec abgebrochen beim user-mismatch.

meine fcgid.conf lautet:

Code: Alles auswählen

 SocketPath /var/lib/apache2/fcgid/sock
  IPCConnectTimeout 20
  AddHandler php-fastcgi .php
  <Location /fcgi/php-fcgi-starter>
     SetHandler fcgid-script
     Options +ExecCGI
  </Location>
   Action php-fastcgi /fcgi/php-fcgi-starter
  AddType application/x-httpd-php .php

mein Vhost:

Code: Alles auswählen

<VirtualHost *:80>
        ServerAdmin me@domain.de
        ServerName domain.de
        ServerAlias www.domain.de

        DocumentRoot /var/www/default/web
        DirectoryIndex index.php index.html index.htm

        SuExecUserGroup vhostuser vhostgroup


       <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>

        <Directory /var/www/default>
                Options FollowSymLinks
                AllowOverride AuthConfig
                Order allow,deny
                allow from all
                FCGIWrapper /var/www/php-fcgi-scripts/default/php-fcgi-starter .php
        </Directory>

        ScriptAlias /fcgi/ /var/www/php-fcgi-scripts/default/
           <Directory "/var/www/php-fcgi-scripts/default">
              AllowOverride None
              Options +ExecCGI -MultiViews -Indexes
              Order allow,deny
              Allow from all
           </Directory>
        AddHandler php4-fastcgi .php4
        AddHandler php-fastcgi .php

        ErrorLog /var/log/apache2/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel debug

        CustomLog /var/log/apache2/access.log combined
        ServerSignature On

        Alias /icons/ "/usr/share/apache2/icons/"
        <Directory "/usr/share/apache2/icons">
            Options Indexes MultiViews
            AllowOverride None
            Order allow,deny
            Allow from all
        </Directory>
</VirtualHost>

meine Ordnerstruktur: (mein Vhost lautet default)

Code: Alles auswählen

drwxr-xr-x  4 root      root       1024 2007-02-28 12:30/var/www/default
drwxr-xr-x  2 root      root       1024 2007-02-28 12:58 /var/www/default/conf
-rw-r--r--  1 root root 20 2007-02-28 12:58 /var/www/default/conf/php.ini

drwxr-xr-x  2 vhostuser vhostgroup 1024 2007-02-28 14:07 /var/www/default/web
-rwx------  1 root root 17 2007-02-28 10:07 /var/www/default/web/index.php
-rwx------  1 vhostuser vhostgroup 19 2007-02-28 13:55 /var/www/default/web/test.php

Eigentlich sollte ja die index.phph wegen falschen Besitzer nicht laufen.. tut sie aber solang ich sie mit 777 ausgestattet habe...

Mein Suexec gibt jetzt wieder ausgaben auf dem Logfile aus, eit meich alles von mod_fastcgi getilgt habe...

leider immer nur

Code: Alles auswählen

[2007-03-10 19:56:33]: uid: (1001/vhostuser) gid: (1001/1001) cmd: php-fcgi-starter

also leider nix mit usermismatch oder sowas, was mir zeigne würde das suexec im Fehlerfall die Ausführung verhindern würde.

Danke Torben

[Kase]

Baue mal deine Configs anders auf...

Aus der fcgid.conf kannst du alles andere rausnehmen außer

Code: Alles auswählen

  AddHandler fcgid-script .fcgi
  SocketPath /var/lib/apache2/fcgid/sock

Mehr brauchst du nicht.

Aus deinem vHost kannst du folgendes machen:

Code: Alles auswählen

<VirtualHost *:80>
        ServerAdmin me@domain.de
        ServerName domain.de
        ServerAlias www.domain.de

        DocumentRoot /var/www/default/web
        DirectoryIndex index.php index.html index.htm

        SuexecUserGroup vhostuser vhostgroup

       <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>

        <Directory /var/www/default>
                Options -All +FollowSymlinks +ExecCGI
                AllowOverride AuthConfig
                Order allow,deny
                allow from all
                # FCGID-PHP-Teil
                FCGIWrapper /var/www/php-fcgi-scripts/default/php-fcgi-starter .php
               AddHandler fcgid-script .php
        </Directory>

        ErrorLog /var/log/apache2/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel debug

        CustomLog /var/log/apache2/access.log combined
        ServerSignature On

        Alias /icons/ "/usr/share/apache2/icons/"
        <Directory "/usr/share/apache2/icons">
            Options Indexes MultiViews
            AllowOverride None
            Order allow,deny
            Allow from all
        </Directory>
</VirtualHost>

Du solltest nahezu copy&paste machen können. Du hast extrem viele Directiven drin, die du überhaupt nicht benötigst.

Deine gepostete Log

Code: Alles auswählen

[2007-03-10 19:56:33]: uid: (1001/vhostuser) gid: (1001/1001) cmd: php-fcgi-starter

sieht sehr gut aus, genauso soll sie aussehen. Suexec startet deinen php-fcgi-starter als 1001, exakt richtig.

Deine PHP-Dateien sollten alle vhostuser:www-data mit den Rechten 740 sein.

Code: Alles auswählen

chown vhostuser:www-data /var/www/default/web
chown vhostuser:www-data /var/www/default/web/*
chmod 740 /var/www/default/web/*

[Zonk]

ok habs eingesetzt, Server läuft auch, soweit bin ich glücklich.

nun zur Masterfrage: verhindert Suexec jetzt die ausführung der Kuckukseier?

leider nein, man kann noch imemr phpdateien eines beliebigen Owners ausführe, solang der nur Nett genug ist die datei auf 777 zu setzen..

Was macht denn dein Apache, wenn du im Docroot eine test.php öffnen magst die dem user root:root gehört?

[Kase]

Zuerst solltest du nachsehen, ob die php-fcgi-starter wirklich dem User vhostuser gehören.

Code: Alles auswählen

debian:~# ps ax -o pid,user,group,cmd | grep php | grep -v grep
 2602 timo     timo     /usr/bin/php5-cgi

Hier gehören sie "timo timo", du hast aber erst php-fcgi Prozesse, wenn du nach einem Serverneustart min 1 php Datei ausgeführt hast.

----------

Php Dateien, die chmod 777 sind, können IMMER ausgeführt werden. Das ist leider nicht zu verhindern, mit dieser Config.

Du solltest in deinem FTP oder SCP Server einstellen, dass neue Files USER:www-data 740 sind, dann kannst du sicher gehen, dass kein vHost die Dateien eines anderen sehen kann.

Durch die richtige Konfiguration haben deine User überhaupt kein Grund, die Dateien 777 zu chmodden. Bei mod_php muss man das manchmal, weil man sonst keine Schreibrechte auf die Files hat. Dies entfällt hier aber, da suexec die Prozesse ja auf den richtigen User setzt.

Am besten du liest dir dazu nochmal diesen Post durch, da habe ich eigentlich alles recht ausführlich erklärt:

http://www.debianforum.de/forum/viewtop ... 890#498890

Suexec ist wie gesagt nicht dazu da, die Fehler von Usern auszugleichen. Suexec setzt User und Group von deinen PHP-Prozessen, damit man mit PHP keine fremden Files zB mit http://www.php.net/system öffnen kann. Natürlich ist hier Vorraussetzung die richtige Config, sprich vhostuser:www-data 740.

Wenn du sicher gehen willst, dass die User keine Quatsch machen, kannst du auch hier einen Cron machen, der die Rechte recursiv immer richtig setzt, siehe anderer Post. Du könntest sogar dich und den User per Mail benachrichtigen, wenn du Scripte findest, die irgendwelche Rechte für OTHERS haben. (man bash)

Edit: Dein scp/ftp Server muss natürlich ins Verzeichnis deines Users "chrooten", sonst kann man evtl fremde files per FTP einsehen, da man ja read Rechte über die Gruppe hat. Apache macht das ja quasi automatisch mittels DocRoot, eine Chroot Option bieten allerdings alle gängigen FTP und SCP Server.