Una operación bastante típica que me toca realizar, en ambiente *nix, bastante seguido es el cambio de permisos de directorios y archivos. Típicamente es asignar permisos de lectura y ejecución para todos los usuarios. No voy a explicar como usar el chmod básico, pero si me referiré al no tan conocido (al menos por aquí) sticky bit y el set-ID.
Tomemos el caso de los scripts shell para iniciar algún servicio. Particularmente puede interesarnos que todos los usuarios puedan ejecutarlos, pero que el proceso quede corriendo bajo algún usuario o grupo en particular, y además nos interesaría que el único (ir)responsable de hacer determinadas barbaridades sobre el archivo o directorio, como por ejemplo cambiarle el nombre, eliminarlo o desvincular su enlace simbólico, sea el propietario original.
Para ello usaremos el sticky bit y el set-ID.
El sticky bit (parámetro t del comando) nos asegura lo segundo, es decir que el propietario sea el amo y señor de los archivos y directorios a los cuales se aplique. Debo ser sincero al reconocer que esto es lo poco y nada que entendí del manual.
El set-ID (parámetro s del comando) nos asegura que cada vez que ejecutemos el script este quede con el usuario o grupo dueño del archivo.
Con un ejemplo, supongamos que tenemos en nuestra carpeta /etc/init.d el script para iniciar el servidor de aplicaciones JOnAS, archivo al que nombraremos originalmente jonas . Dado que es un servicio querremos que corra como usuario root , así que lo creamos usando ese usuario, o en su defecto cambiamos el usuario usando el comando chown .
Entonces desde una consola y estando conectados al sistema como root, ejecutamos la siguiente secuencia de comandos:
Tomemos el caso de los scripts shell para iniciar algún servicio. Particularmente puede interesarnos que todos los usuarios puedan ejecutarlos, pero que el proceso quede corriendo bajo algún usuario o grupo en particular, y además nos interesaría que el único (ir)responsable de hacer determinadas barbaridades sobre el archivo o directorio, como por ejemplo cambiarle el nombre, eliminarlo o desvincular su enlace simbólico, sea el propietario original.
Para ello usaremos el sticky bit y el set-ID.
El sticky bit (parámetro t del comando) nos asegura lo segundo, es decir que el propietario sea el amo y señor de los archivos y directorios a los cuales se aplique. Debo ser sincero al reconocer que esto es lo poco y nada que entendí del manual.
El set-ID (parámetro s del comando) nos asegura que cada vez que ejecutemos el script este quede con el usuario o grupo dueño del archivo.
Con un ejemplo, supongamos que tenemos en nuestra carpeta /etc/init.d el script para iniciar el servidor de aplicaciones JOnAS, archivo al que nombraremos originalmente jonas . Dado que es un servicio querremos que corra como usuario root , así que lo creamos usando ese usuario, o en su defecto cambiamos el usuario usando el comando chown .
Entonces desde una consola y estando conectados al sistema como root, ejecutamos la siguiente secuencia de comandos:
chmod 755 jonas
chmod u+st jonas
Y listo. Explicacion:
chmod 755 jonas : asigna permisos de ejecución y lectura para todos los usuarios, el propietario (en este caso root ) además puede excribir sobre el archivo.
chmod u+st jonas : operando sobre el usuario (por eso el parámetro u ) le fija un sticky bit y además un set-ID , de manera que al ejecutarse el script el proceso asociado queda corriendo como si hubiera sido ejecutado por el usuario root .
De sobra está mencionarles que existe una dosis de peligro al asignar permisos de esta manera, pués usuarios maliciosos desearían poder mal utilizar este poder, pero eso no es de mi responsabilidad :)
chmod 755 jonas : asigna permisos de ejecución y lectura para todos los usuarios, el propietario (en este caso root ) además puede excribir sobre el archivo.
chmod u+st jonas : operando sobre el usuario (por eso el parámetro u ) le fija un sticky bit y además un set-ID , de manera que al ejecutarse el script el proceso asociado queda corriendo como si hubiera sido ejecutado por el usuario root .
De sobra está mencionarles que existe una dosis de peligro al asignar permisos de esta manera, pués usuarios maliciosos desearían poder mal utilizar este poder, pero eso no es de mi responsabilidad :)
