Finalement j'ai résolu ça. Merci à @JimB, car dans son commentaire, il a souligné SUEXEC, que je ne connaissais pas (ou que j'ignorais simplement jusqu'à présent).
Après avoir lu un peu la documentation suEXEC, j'ai compris que le problème devait être là. J'ai donc jeté un œil à la configuration :
# suexec -V
-D AP_DOC_ROOT="/var/www"
-D AP_GID_MIN=1000
-D AP_HTTPD_USER="apache"
-D AP_LOG_SYSLOG
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=1000
-D AP_USERDIR_SUFFIX="public_html"
et tout semblait OK (bon uid/gid pour mon utilisateur, userdir_suffix est bien, etc.). J'ai donc jeté un coup d'œil aux journaux système :
# journalctl -b | grep "suexec"
May 22 11:43:12 caladan suexec[5397]: uid: (1000/user) gid: (1000/user) cmd: test.cgi
May 22 11:43:12 caladan suexec[5397]: directory is writable by others: (/home/user/public_html/cgi-bin)
et c'est le problème :mon cgi-bin répertoire était accessible en écriture par d'autres .
J'ai corrigé en changeant simplement les autorisations en 755 .
Cela se produit parfois lorsque vous essayez d'appeler d'autres méthodes de module Python à partir de votre cgi où vous avez peut-être laissé des instructions 'print' (peut-être pour le débogage). Scannez donc votre code pour toute instruction "print", parfois cela résout facilement le problème.
Pour moi, cela a fonctionné lorsque j'ai changé la ligne shebang (#!/usr/bin/sh ) à #!/usr/bin/env sh . J'ai trouvé que toutes les lignes de shebang de Quel est le shebang Bash préféré? semblait fonctionner (notez cependant que sh est différent de bash donc si vous voulez utiliser sh tenez-vous-y).
Donc ce code a fonctionné pour moi :
#!/usr/bin/env sh
echo "Content-type: text/plain"
echo ""
echo "Hello"
De plus, selon le post mentionné ci-dessus, il semblerait que /usr/bin/env sh semble préféré à /bin/sh . Je n'ai aucune idée des trucs par répertoire.