Si realmente quiere que su código sea robusto en una amplia variedad de configuraciones de Linux, le sugiero que considere los casos de esquina donde alguien puede estar utilizando SELinux, o ACL del sistema de archivos, o las características de "capacidades" que han sido en el núcleo de Linux desde la v. 2.2 más o menos. Su proceso podría estar ejecutándose bajo algún envoltorio que haya usado SELinux, o alguna biblioteca de capacidades Linux, como libcap2libcap-ng, o fscaps o elfcap a través de algo más exótico como el maravilloso y lamentablemente poco apreciado sistema systrace de Niels Provos.
Todas estas son formas en que el código podría estar ejecutándose como no raíz y, sin embargo, su proceso podría haber sido delegado el acceso necesario para realizar su trabajo sin EUID == 0.
Así que le sugiero que considere escribir su código más Pythonically, envolviendo las operaciones que pueden fallar debido a permisos u otros problemas con el código de manejo de excepciones. Si realiza bombardeos para realizar diversas operaciones (por ejemplo, utilizando el módulo subprocess
), puede ofrecer prefijar todas las llamadas con sudo
(como línea de comando, entorno o opción de archivo .rc, por ejemplo). Si se ejecuta de forma interactiva, puede ofrecer volver a ejecutar los comandos que generan excepciones relacionadas con permisos usando sudo
(opcionalmente solo si encuentra sudo
en os.environ ['RUTA']).
En general, es cierto que la mayoría de los sistemas Linux y UNIX aún tienen la mayor parte de su administración realizada por un usuario con privilegios 'raíz'. Sin embargo, es de la vieja escuela y nosotros, como programadores, deberíamos intentar apoyar modelos más nuevos. Probar sus operaciones y dejar que el manejo de excepciones haga su trabajo permite que su código funcione bajo cualquier sistema que permita de manera transparente las operaciones que necesita, y estar al tanto y listo para usar sudo
es un buen toque (ya que es, de lejos, el más herramienta generalizada para la delegación controlada de privilegios del sistema).
Esta es la forma más portátil e incluso funciona en circunstancias un poco más exóticas, como con privilegios de raíz de limitación de SELinux. –
Esto en realidad puede ser peor dependiendo de la situación. Hmm, pero Florian tiene un punto. –
@Longpoke: ¿se refiere a la situación en la que un usuario puede haber cambiado el nombre de los permisos en/etc pero, por ejemplo, no tiene la capacidad de eliminar un archivo de esa ruta? Si eso es lo que quieres decir, entonces tratar de determinar qué capacidades tiene el usuario de antemano es una misión tonta. Es mejor estructurar el código para la semántica "transaccional", donde A y B pueden retrotraerse si C falla. – msw