CentOS aquí, pero no creo que eso importe porque estodeberíaser una pregunta central de Linux (creo). Mientras intentaba instalar y ejecutar Apache Kafka (un ejecutable de Java) en una máquina CentOS, pensé en una pregunta que se aplica a Linux en general.
Cuando ejecuta un script de shell o un ejecutable nativo (como java), ¿el script/ejecutable dicta con qué usuario se ejecuta, o el sistema operativo dicta con qué usuario se ejecuta el script/ejecutable (es decir, qué usuario está ejecutando el script? /ejecutable)?
¿Es posible y/o típico que los procesos dicten con qué usuario se ejecutan? Significadopoder¿Un script/aplicación especifica que debe ejecutarse como usuario root o como algún otro tipo específico de usuario?
De cualquier manera, ¿por qué existe una advertencia general sobre ejecutar procesos como root en lugar de ejecutarlos como usuarios sin privilegios?
Respuesta1
Respuesta corta: ambos.
Respuesta más larga (y mucho más útil): de forma predeterminada, el programa se ejecutará como el usuario que lo inició. Sin embargo, un programa puede, si se escribe para hacerlo y se le otorgan los permisos correctos, asumir privilegios de root y/o volver a un usuario del "sistema" para ejecutarse. Sin embargo, esta capacidad debe otorgarse explícitamente al programa, ya sea a través del proceso de empaquetado e instalación o mediante acciones tomadas por el administrador de esa máquina.
La advertencia general está ahí porque la experiencia histórica en UNIX y Linux ha demostrado que muy a menudo los programas que usan privilegios elevados (es decir, root) que no necesitan a menudo le harán cosas malas al sistema. Esto puede ser desde corrupción de datos hasta procesos fuera de control que hacen que el resto del sistema sea inutilizable o no responda, hasta procesos que, sin saberlo, permiten a los atacantes acceder a su sistema de maneras que usted no desea.
Respuesta2
Cuando se ejecuta un 'script de shell', se ejecuta con los permisos del usuario que ejecutó ese script. La mayoría de los servicios (kafka, redis, nginx, etc.) instalados mediante un administrador de paquetes (yum, apt, etc.) instalan scripts auxiliares para facilitar el control de esos servicios y crean usuarios de servicios únicos asociados con esos servicios (apache, redis, nginx, etc.) Casi todos estos scripts auxiliares se ejecutan inicialmente como root y luego otorgan privilegios a un usuario de servicio asignado a ese servicio. Esto garantiza que sólo los usuarios autorizados (es decir, los usuarios autorizados para ejecutar "sudo service kafka start") puedan controlar eficazmente esos servicios. Esto significa que la administradora de sistemas Sally puede iniciar, detener y reiniciar kafka y nginx, mientras que el desarrollador Jim puede estar restringido a iniciar y detener solo kafka (o algo así). Si bien el administrador puede crear un usuario de Java, no es algo que yo haya creado. visto en la práctica, al igual que un usuario de Ruby o un usuario de Python. Más bien, la propiedad del servicio suele estar vinculada a un usuario del servicio relacionado con ese servicio en particular.
Algunos procesos dependen de que se ejecuten como root (normalmente el demonio del servidor ssh se ejecuta como root). Otros procesos se negarán a iniciarse como root (postgresql es uno).
Si revisa una secuencia de comandos auxiliar para un servicio en /etc/init.d/someservice (o /etc/init/someservice.conf), las secuencias de comandos reales que causan la escalada o caída de privilegios están codificadas allí. Alternativamente, si ha iniciado sesión como usuario stephan y ejecuta algo como /usr/sbin/redis-server -c /etc/redis.conf, luego verifique ese proceso desde otra ventana, verá que redis es propiedad por esteban.
Espero que ayude.