Puede que la pregunta no sea clara y demasiado amplia, pero cualquier respuesta, por breve o amplia que sea, es muy apreciada.
Hace algún tiempo pedí instalar zsh en nuestro servidor de producción. Las empresas de mis administradores respondieron que no se puede hacer ya que se trata de producción, no de servidor de desarrollo.
Utilicé zsh y oh-my-zsh durante los últimos 5 años y estoy muy apegado a él, zsh hace mi trabajo más fácil y rápido. Pero no fue argumento suficiente.
No soy fuerte en seguridad u otros temas que puedan estar involucrados aquí, por eso mis preguntas son:
- ¿La instalación de zsh en el servidor de producción es inofensiva para el sistema?
- ¿Permitiría instalar zsh en este caso y por qué?
- ¿Tiene sentido restringir a los usuarios con bash en el servidor de producción?
Respuesta1
zshes solo un shell, no inicia ningún servicio, no viene con ningún comando setuid. Entonces, la mera instalación del paquete no hará nada hasta que alguien o algo realmente lo use. Como no necesita ningún privilegio, cualquier usuario puede instalarlo por su cuenta en su directorio personal o en cualquier lugar al que tenga acceso.
si no fueracalidad de la producción, se podría argumentar que convertirlo en el shell de inicio de sesión de un usuario administrador introduciría algún riesgo, pero con su sintaxis mucho más sensata que otros shells como basho tcsh, yo diría que mejoraría las cosas considerablemente.
Aunque su uso principal es como un shell interactivo, yo diría que escribir scripts zshprobablemente haría que los scripts sean más seguros y confiables que bashlos scripts (vea cuántas personas, sin saberlo, escriben bashscripts en zshsintaxis cuando se olvidan de citar sus variables y cómo cambiar el shebang from #! /bin/bashto #! /bin/zsh -solucionaría muchos de los errores en sus scripts).
En cualquier caso, la instalación zshes una de las primeras cosas que he estado haciendo para todas las implementaciones de servidores en todos los lugares en los que he trabajado.
Sin embargo, generalmente no lo convierto en el shell de inicio de sesión de ningún usuario de forma predeterminada, ya que no es raro que algunos programas esperen un entorno centrado en bash.
Respuesta2
Igual que los demás esta es mi opinión:
- ¿La instalación de zsh en el servidor de producción es inofensiva para el sistema?
Defina "inofensivo". En sentido estricto, no causa ningún daño directo. Sin embargo, cualquier código que esté en su sistema de producción es un vector de ataque potencial. En ese sentido, no es verdaderamente "inofensivo", en el sentido de quepodríaser utilizado para un ataque al sistema. También hay otras formas en las que indirectamente podría causar problemas. ZSH consume un poco más de recursos que bash, por ejemplo, lo que podría ser importante en un sistema que funciona cerca de su capacidad.
- ¿Permitiría instalar zsh en este caso y por qué?
Dependiendo de las circunstancias exactas, es posible que ya lo tenga instalado.
Todos mis sistemas personales tienen ZSH instalado y configurado como shell predeterminado para todos, incluido el root. Esto se debe simplemente a que trabajo con bastante regularidad desde un shell local en estos sistemas y uso activamente ZSH en muchos casos.
Sin embargo, todos los sistemas que administro en el trabajo no lo tienen instalado. Alrededor del 95% del trabajo administrativo que hago para ellos no implica que yo toque nunca un caparazón de estos sistemas (hago unlotea través de Ansible en el trabajo), por lo que no tiene sentido que lo convierta en un entorno familiar. También sería muy poco probable que lo instale en algo que no sea nuestros sistemas de desarrollo reales, y no hay ninguna posibilidad de que lo instale en algo a lo que se pueda acceder directamente desde fuera del sitio.
- ¿Tiene sentido restringir a los usuarios con bash en el servidor de producción?
Cuestionaría la viabilidad de permitir que los usuarios habituales toquen los sistemas de producción más allá de ciertos casos muy restrictivos que no implican un acceso real al shell.
Por ejemplo, donde trabajo, sólo el departamento de TI y las personas directamente responsables del mantenimiento de nuestro sitio web tienen algo más que acceso HTTPS regular a nuestros servidores web. El personal de TI (incluido yo mismo) debemos iniciar sesión con una cuenta especial que solo se usa para la administración de los servidores web, e incluso así tienen acceso limitado a los sistemas a menos que estén sentados en la consola física en la sala del servidor. Los diseñadores web solo tienen acceso SFTP a la raíz del sitio web, ynadademás. Dado esto, no hay necesidad de ningún shell excepto bash (que es nuestro estándar interno para uso administrativo).
De manera similar, para nuestros servidores de archivos internos, solo el departamento de TI tiene acceso real al shell. Otros usuarios tienen acceso especialmente limitado a ciertos directorios, lo que generalmente permite protocolos de servidor de archivos regulares (SMB, NFS, etc.), además de SFTP y, en algunos casos, rsync, pero ninguno de ellos tiene acceso real al shell, porque en realidad no lo necesitan. él.
Respuesta3
En mi experiencia, sí, es poco común instalar zsh en un servidor de producción. Dicho esto, trabajo principalmente con clientes más "conservadores" (bancos, administraciones, etc.), por lo que su kilometraje puede variar.
Zsh en sí esinofensivo. Es "sólo otro caparazón", como bash, ksh,... Sin embargo, en muchas corporaciones, la política de seguridad eslimitar al máximo la superficie de ataque, es decir, no instale nada a menos que sea necesario. Aunque zsh es inofensivo,su código base podría contener errores. Leer acerca deNeurosis de guerrasi aún no lo sabes. :)
Dicho esto, existe cierta indulgencia con los 'productos', como tener vim en lugar de solo vi. Zsh podría entrar en esta categoría.No en producción, no esta pasando. Además de reducir la superficie de ataque, también está el hecho de que necesitarás probar dos veces tus scripts: una vez con zsh y otra con bash. Esto requiere tiempo y dinero.
Yo no lo llamaría restringir a bash:¿Hay algo que puedas hacer con zsh que no puedas hacer con bash?
Nota final:bash es prácticamente el estándar de la industria. Es el shell predeterminado para la mayoría de las distribuciones de nivel empresarial (RHEL, SUSE,...), así como para muchas distribuciones muy populares como Debia, Ubuntun...
He probado "nuevos" shells a lo largo de los años: zsh y fish son dos que me gustaron mucho. Sin embargo, para uso doméstico tal vez, en el trabajo sea bash completamente (y ksh cuando se trabaja con AIX, etc.). Termino usando bash en casa también, los viejos hábitos cuestan morir.
Respuesta4
Otras opiniones disponibles, pero aquí está la mía.
- ¿La instalación de zsh en el servidor de producción es inofensiva para el sistema?
La introducción de software nuevo rara vez es inofensiva. Por ejemplo, conlleva la necesidad de garantizar que se identifiquen y parcheen las vulnerabilidades asociadas.
- ¿Permitiría instalar zsh en este caso y por qué?
No. Me gustaría que se identificara un beneficio tangible.
- ¿Tiene sentido restringir a los usuarios con bash en el servidor de producción?
Sí, bashes genial :-) Y si algún grupo específico de usuarios de la empresa comienza a escribir zshscripts sin que los equipos de soporte más amplios tengan conocimiento de ello, se enfadan.