Lo hice y lo entendí

El blog de Vicente Navarro
05 abr

El Sticky Bit y el SGID en directorios

Todos los ficheros y directorios en un sistema UNIX tienen asociado un número compuesto de cuatro cifras en octal. Los tres dígitos menos significativos (least significant digit) especifican los permisos que tienen los usuarios sobre ese fichero (lectura (r), escritura (w) y ejecución (x) para el usuario, los usuarios pertenecientes al grupo o para otros):

sst rwx rwx rwx
421 421 421 421
S   U   G   O

S=SUID, SGID y Sticky Bit
U=Usuario
G=Grupo
O=Otros

Esto forma parte de los conocimientos básicos y mínimos de cualquier usuario de UNIX y podemos leer sobre ello en Permisos de ficheros del manual Seguridad en UNIX y Redes. También es muy conocida la existencia de los bits SUID y SGID, formados por los dos bits más significativos del octal más significativo. Aplicados sobre un fichero ejecutable, permiten que el programa se ejecute como si lo hiciera el usuario propietario (SUID) o el grupo propietario(SGID) del fichero.

Pero el propósito de esta entrada es resaltar la curiosidad, bastante menos conocida, de aplicar el bit menos significativo de la cifra octal más significativa (el que en el esquema anterior he marcado con una t), el Sticky Bit, a un directorio (aplicado a un fichero no se usa para nada en la gran mayoría de los UNIX modernos). En el man del chmod leemos:

STICKY DIRECTORIES
When the sticky bit is set on a directory, files in that directory may
be unlinked or renamed only by root or their owner. Without the sticky
bit, anyone able to write to the directory can delete or rename files.
The sticky bit is commonly found on directories, such as /tmp, that are
world-writable.

Es decir, en directorios como el /tmp o el /var/tmp donde todos los usuarios del sistema pueden hacer lo que quieran si los permisos son (0777), en la mayoría de los casos nos interesará poner el Sticky Bit (permisos 1777) para que un usuario no pueda borrar o renombrar ficheros de otros usuarios.

Y todavía más curioso y desconocido es el efecto del SGID sobre directorios. Al ponerlo, estamos diciendo que todos los ficheros y directorios que se creen por debajo de aquél que tiene SGID se creen con el mismo grupo propietario. En el caso de directorios, se crearán a su vez con el SGID puesto para que sus subdirectorios tengan el mismo comportamiento (menos mal que los ficheros no lo heredan, vaya problema de seguridad que sería).

En el siguiente ejemplo podemos ver que cuando un directorio perteneciente a usuarioprueba/grupoprueba tiene el SGID, los subdirectorios y ficheros creados por debajo de él por usuarioprueba2/grupoprueba2 también pertenecerán a ese grupo. Eso sí, si los permisos del directorio y el Sticky Bit lo permiten, el grupo lo podríamos cambiar posteriormente a mano.

$ id
uid=1000(usuarioprueba) gid=100(grupoprueba)
$mkdir directorio
$ chmod 2777 directorio
$ ll -d directorio
drwxrwsrwx 2 usuarioprueba grupoprueba 4096 2007-04-04 22:38 directorio/

$ id
uid=2000(usuarioprueba2) gid=200(grupoprueba2)
$ mkdir directorio/subdirectorio
$ ll directorio
drwxr-sr-x  2 usuarioprueba2 grupoprueba 4096 2007-04-04 22:39 subdirectorio
$ touch directorio/fichero
$ ll directorio/fichero
-rw-r--r--  1 usuarioprueba2  grupoprueba 0 2007-04-04 22:52 fichero

Podríamos pensar que el mismo comportamiento con usuarios en lugar de con grupos ocurre con el SUID sobre un directorio, pero la inmensa mayoría de los UNIX no lo hace así (setuid on directories), y si lo pensamos, tiene sentido: usa cosa es que cuando creemos ficheros en el directorio de otro usuario se pierda la propiedad del grupo, pero es muy distinto que tan pronto como lo guardemos perdamos propiedad sobre él causando en algunos casos que incluso pudiéramos volver a acceder a él.

Entradas relacionadas

11 Comentarios a “El Sticky Bit y el SGID en directorios”

  • fpuga dice:

    Una buena entrada. Nunca está de más recordar la potencia del sistema de permisos en los sistemas UNIX. Hace poco escribí una entrada sobre como compartir el dispositivo de sonido entre varios usuarios

  • fpuga Muchas gracias

  • cruzki dice:

    Llevo tiempo buscando una solución a un problema que tengo. Quiero hacer un directorio “público” entre los usuarios de un ordenador, donde “público” no sólo significa que el directorio tiene permisos 777 sino que TODO ARCHIVO QUE SE ESCRIBA allí los herede. Esto no presenta ningún problema de seguridad, puesto que es un DIRECTORIO público para facilitar el intercambio de archivos y demás.

    El asunto es que con permisos a secas creo que no se puede hacer y la única solución que se me ocurre es hacer poner un cron, cada minuto o así, que cambie los permisos recursivamente. Pero esta solución es fea, fea, además de ineficiente. ¿Teneis alguna sugerencia?

  • Ivan dice:

    Me ha gustado mucho esta entrada. La verdad es que no conocía la existencia de ese bit y conviene siempre refrescar estos conocimientos.

    Saludos, Iván

  • cruzki Creo que lo que comentas se podría lograr con las ACLs de Linux. No las he usado nunca, pero leyendo el artículo que enlazo parece que proporcionan la flexibilidad necesaria para lograr cosas como las que planteas.

    Ivan ¡Muchas Gracias!

  • cruzki dice:

    Gracias por el enlace. Le echare un ojo a ver si es la solución ;)

  • cruzki dice:

    En principio la solución es buena. Pero voy a tener que recompilar el kernel (uso gentoo) puesto que tengo que activar las opciones avanzadas de EXT3.

  • cruzki Pues ya nos contarás. Si luego te apetece contar tu experiencia por aquí, dímelo y a ver cómo lo podemos hacer.

  • Gonzalo dice:

    Excelente: no sabia de este atributo y, hasta este momento, me ha resuelto el problema de que un usuario de un grupo entre a un archivo y lo “secuestre” cambiandole sus atributo de tal manera que otro usuario, incluso el propietario, le aparezca como “solo lectura”
    muchas gracias.

  • @Gonzalo ¡Me alegro de que te haya resultado de ayuda!

Trackbacks y pingbacks:

Tema LHYLE09, creado por Vicente Navarro