Establecer la ejecución correcta en todo el directory: ¿es buena o mala idea?

Tengo un file zip que contiene muchos files y directorys para una determinada aplicación que debería ejecutarse en Linux. Algunos files deben configurarse como ejecutables, pero el formatting de file zip afaik no conserva los derechos de ejecución.

Necesito configurar manualmente la ejecución en los files después de extraer el file y (estoy llegando a eso) mi pregunta es:

Si no sé qué files deben ser ejecutables, ¿es una buena idea agregar el permiso de ejecución recursivamente a todo el directory? ¿Puede poseer algún riesgo de security? ¿Alguien sabe de otros problemas que pueda causar?

No existe ningún riesgo de security directo al hacer que un file sea ejecutable a less que sea setuid o setgid. Por supuesto, existe el riesgo indirecto de que algo que esperas que sea inerte, algún file de datos que normalmente abrirías en una aplicación, también se puede ejecutar directamente en tu sistema con nefastas consecuencias. Por ejemplo, si tiene un file llamado README que realmente contiene un progtwig de rootkit, abrirlo en un editor de text es seguro, pero será mejor que no lo ejecute.

Una heurística razonable para reconocer files que deben ser ejecutables es observar sus primeros bytes y reconocer las firmas ejecutables. Esta es una cuestión de conveniencia más que de security, pero si está dispuesto a hacer que todos los files sean ejecutables de todos modos, significa que no tiene un problema de security sino de utilidad. Aquí hay una posible heurística:

 for x in *; do case $(file - <"$x") in *executable*) chmod +x -- "$x";; esac done 

Aquí hay otra heurística que debería diferir solo en casos de esquina ( $'\177' es la syntax ksh / bash / zsh, reemplácela por un carácter literal 0177 = 127 = 0x7f en otros shells).

 for x in *; do case $(head -c 4 <"$x") in '#!'*|$'\177'ELF) chmod +x -- "$x";; esac done 

En ambos casos, el hecho de que un file se reconozca como ejecutable no significa que pueda ejecutarlo en su sistema; por ejemplo, un binary para una architecture de procesador incorrecta será felizmente ejecutable. Este es un enfoque diferente que hace que todos los scripts sean ejecutables, pero binarys vinculados dinámicamente solo si son para la architecture correcta y usted tiene las bibliotecas necesarias, y omite por completo los binarys estáticamente vinculados.

 for x in *; do case $(head -c 2 <"$x") in '#!') chmod +x -- "$x";; *) if ldd -- "$x" >/dev/null 2>/dev/null; then chmod +x "$x"; fi;; esac done 

No es bonito ni elegante, pero agregar el bit ejecutable a un file que no es ningún tipo de ejecutable con el que el sistema operativo sabe qué hacer no es dañino; si lo intenta, es probable que cannot execute binary file

Un posible riesgo serían los files de text si de alguna manera las primeras palabras resultan ser commands válidos en el shell, pero eso es difícil de pnetworkingecir (si es poco probable).

Personalmente, me equivoco por precaución y mantengo todo no ejecutable, luego escribo un guión rápido para orderar todos los files con el command de file y volteo el bit ejecutable si es reconocido como un script o un código binary ELF – código exacto dejó como un ejercicio para el lector.

Respuesta simple, sí, puede plantear riesgos de security, pero estos dependen completamente de los requisitos específicos de control de acceso para los files y directorys involucrados.

Su mejor opción es preguntarle al propietario / desarrollador / etc de la aplicación si hay algún file o directory que requiera el cumplimiento de los permissions, así como si hay alguno que deba configurarse como ejecutable. Debería ser su llamado, no el tuyo, por lo que evitaría tomar la responsabilidad si no conoces los requisitos de la aplicación.

Es posible que los numbers sean bajos, por lo que se convierte en un process simple. YMMV