Con Bash sourcees posible ejecutar un script sin un bit de ejecución establecido. Este es un comportamiento documentado y esperado, pero ¿no va en contra del uso de un bit de ejecución?
Lo sé, eso sourceno crea una subcapa.
Respuesta1
sourceo el equivalente pero estándarpunto.no ejecute el script, peroleerlos comandos del archivo de script, luego ejecútelos, línea por línea, en el entorno de shell actual.
No hay nada en contra del uso del bit de ejecución, porque el shell sólo necesitaleerpermiso para leer el contenido del archivo.
El bit de ejecución sólo es necesario cuandocorrerla secuencia de comandos. Aquí el shell realizará fork()un nuevo proceso y luego usaráexecve()función para crear una nueva imagen de proceso a partir del script, que debe ser un archivo ejecutable normal.
Respuesta2
Bash es un intérprete; acepta entradas y hace lo que quiere. No es necesario prestar atención al bit ejecutable. De hecho, Bash es portátil y puede ejecutarse en sistemas operativos y sistemas de archivos que no tienen ningún concepto de bit ejecutable.
Lo que sí le importa al bit ejecutable es el kernel del sistema operativo. Cuando el kernel de Linux realiza una ejecución exec, por ejemplo, verifica que el sistema de archivos no esté montado con una noexecopción, verifica el bit ejecutable del archivo de programa y aplica los requisitos impuestos por los módulos de seguridad (como SELinux o AppArmor).
Tenga en cuenta que el bit ejecutable es un tipo de control bastante discrecional. En un sistema Linux x86-64, por ejemplo, puede omitir la verificación del kernel del bit ejecutable alinvocando explícitamente /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2como intérprete:
cp /bin/ls /tmp/
chmod -x /tmp/ls
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /tmp/ls
Esto es algo análogo a obtener el código fuente de Bash en Bash, excepto que ld.soes el intérprete y el código que ejecuta es código de máquina en formato ELF.
Respuesta3
El bit ejecutable (a diferencia del resto) en archivos no setuid y no setguid no es un gran mecanismo de seguridad. Cualquier cosa que puedas leer, puedes ejecutarla indirectamente, y Linux te permitirá leer indirectamente cualquier cosa que puedas ejecutar pero no leer directamente (eso debería ser suficiente para perforar el concepto de que el x-bit no establecido(g)uid es un medida de seguridad).
Es más una cuestión de conveniencia: deje que el sistema lo ejecute directamente si el bit está configurado; de lo contrario, tendré que hacerlo indirectamente ( bash the_script;o algo así).Hackear para obtener la imagen de la memoria de un ejecutable sin permiso de lectura.).
Puede configurarlo para su comodidad si tiene la intención de obtener y ejecutar su insourcable.
Aparentemente, sin embargo, muchos implementadores de bibliotecas compartidas comparten su pensamiento y, en consecuencia, muchos sistemas requieren que las bibliotecas compartidas, que son esencialmente el equivalente nativo de los shell insourcables, estén marcadas como ejecutables para poder usarse. Ver¿Por qué las bibliotecas compartidas son ejecutables?.
Respuesta4
En lo que respecta al sistema operativo, un archivo que contiene un script de shell son solo datos. Si pasa el nombre de dicho archivo de datos al sourcecomando o lo pasa en la línea de comando a una invocación del shell bash, todo lo que ve el sistema operativo es una cadena que coincide con el nombre de un archivo que contiene datos.
¿Cómo sería relevante el bit de ejecución en ese caso?