Finalmente resolví eso. Gracias a @JimB, porque en su comentario señaló SUEXEC, que no conocía (o simplemente ignoré hasta ahora).
Después de leer un poco la documentación de suEXEC, entendí que el problema tenía que estar ahí. Entonces, eché un vistazo a la configuración:
# 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"
y todo se veía bien (buen uid/gid para mi usuario, userdir_suffix está bien, etc.). Así que eché un vistazo a los registros del sistema:
# 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)
y eso es el problema:mi cgi-bin otros usuarios podían escribir en el directorio .
Lo solucioné simplemente cambiando los permisos a 755 .
Esto a veces surge cuando intenta llamar a otros métodos de módulos de Python desde su cgi donde podría haber dejado algunas declaraciones de 'impresión' (quizás para depurar). Así que escanee su código en busca de cualquier declaración de 'impresión', a veces esto soluciona el problema fácilmente.
Para mí, funcionó cuando cambié la línea shebang (#!/usr/bin/sh ) a #!/usr/bin/env sh . Descubrí que cualquier línea shebang de ¿Cuál es el shebang Bash preferido? parecía funcionar (sin embargo, tenga en cuenta que sh es diferente de bash así que si quieres usar sh quedarse con eso).
Así que este código funcionó para mí:
#!/usr/bin/env sh
echo "Content-type: text/plain"
echo ""
echo "Hello"
Además, según la publicación mencionada anteriormente, parece /usr/bin/env sh parece preferible a /bin/sh . No tengo idea sobre las cosas por directorio.