Creo que estás en lo correcto si el usuario httpd tiene más derechos de los que debería tener el desarrollador.
También cuando tengo mis reglas y el desarrollador no quiere escucharlas, simplemente le paso el trabajo al siguiente jugador de la fila.
Los riesgos:
- Necesitan acceso de shell a sus máquinas
- Necesitan acceso al usuario httpd (pueden controlar sus servidores web básicamente)
Cualquiera de lo anterior significa que pueden jugar con cosas con las que no deberían estar jugando. Aparte de eso, pueden configurar su servidor web para que SOLAMENTE funcione con sus scripts, lo que significa que si alguna vez rompe el contrato con ellos, se sentirá muy lastimado al corregirlo. (Esta es una posibilidad, sin decir que lo harán)
Si les permite el acceso mediante shell, le aconsejo que, por contrato (!), saque lo que pueden tocar y lo que no pueden. (Habla suavemente con un palo grande)
Como usted está diciendo, si sus scripts solo deberían escribirse en un determinado directorio, entonces definitivamente no hay necesidad de darles nada más que un shell que pueda escribir en la carpeta web. Si necesitan acceso a ciertos archivos de configuración, puede agregarlos al grupo httpd. Si necesitan acceso para reiniciar un servidor web, simplemente les da sudo para el comando de reinicio.
Nunca le dé a nadie más autorización de la que necesita para hacer el trabajo. Si el marketing persiste, describa muy cuidadosamente qué puede suceder si estos desarrolladores fallan y crean un tiempo de inactividad y cómo esto puede afectar la imagen de la empresa. Asegúrate de cubrirte también.
EDIT
¿Quieren ejecutar sus propios scripts de acceso como usuarios de httpd para que puedan tener acceso completo de escritura con un navegador?
Esto no es realmente una buena idea, si esa cosa se rompe, te duele mucho.
Lo mejor que puedo encontrar en este momento es esta guía nist: enlace (ver capítulo 5.2)
un artículo de searchsecurity sobre por qué debería usar un servidor dev:
enlace