Primero una introducción de los permisos
Unix y Linux (incluyendo Mac OS X y otros sistemas compatibles con POSIX) tienen un sistema (relativamente) simple para controlar el acceso a los archivos y directorios. Este sistema se define en POSIX.1: 2008, también conocido como el Single Unix Specification (SUS versión 4). Y puesto que los dispositivos tales como discos, puertos, etc tienen nombres de archivo (en /dev) se controla el acceso a ellos de la misma manera.
Este sistema funciona mediante la asignación de un usuario y un grupo para cada archivo. A continuación, los usuarios de ese archivo se ponen en una de tres clases:
el propietario (UID del proceso coincide con el usuario del archivo),
el grupo (no es el dueño, pero el GID del proceso pertenece al grupo del archivo),
y otros (todos los demás).
Para cada categoría de usuarios, hay tres posibles permisos que se pueden conceder:
leer,
escribir y
ejecutar.
Además de estos permisos estándar, hay tres "atributos" que se pueden establecer en cualquier archivo (estos son comúnmente denominadas también permisos):
El set user ID (o SUID),
El set group ID grupo (o SGID), y
El atributo texto (o pegajoso).
SUID en un archivo
Si a cualquier clase de usuario se le concede el permiso de ejecución de un archivo, el bit SUID hace que el propietario del proceso sea el del archivo y no el usuario que ejecuta el programa. Así que si el programa intenta leer algo, los permisos que se aplican sería que el propietario del archivo y no el usuario del programa.
Por ejemplo, supongamos que el usuario Jane ejecuta el comando "vista memo.txt", y los permisos del comando vista y el memo.txt son los siguientes:
Jane tiene permiso para ejecutar vista, pero no el permiso para leer memo.txt. Así que cuando este programa intenta leer el archivo ocurrirá un error "permiso denegado".
Supongamos que cambiamos el programa para tener el bit SUID:
Ahora, cuando Jane ejecuta este programa, el acceso a memo.txt está permitido. Cuando vista intente la lectura del archivo, el sistema no cree que Jane está tratando de leer, piensa que "root" es el usuario. Así se permite el acceso.
Una sustitución similar se produce si el bit SGID se establece y los bits de ejecución se establecen. El ID del grupo controlado no es el del usuario actual, sino del grupo del programa.
Técnicamente, cada proceso tiene un usuario real (RUID) y un grupo real (RGID). Estos son los usuarios y grupos de la persona que inició el proceso mediante la ejecución de algún programa. Cada proceso tiene un identificador de usuario efectivo euid y egid. Por defecto estos son los mismos. Sin embargo, si se ejecuta un programa que tiene el bit SUID o SGID, el UID efectivo o GID efectivo pasa a ser los del archivo, no de la persona que lo ejecuta.
Unix y Linux (incluyendo Mac OS X y otros sistemas compatibles con POSIX) tienen un sistema (relativamente) simple para controlar el acceso a los archivos y directorios. Este sistema se define en POSIX.1: 2008, también conocido como el Single Unix Specification (SUS versión 4). Y puesto que los dispositivos tales como discos, puertos, etc tienen nombres de archivo (en /dev) se controla el acceso a ellos de la misma manera.
Este sistema funciona mediante la asignación de un usuario y un grupo para cada archivo. A continuación, los usuarios de ese archivo se ponen en una de tres clases:
el propietario (UID del proceso coincide con el usuario del archivo),
el grupo (no es el dueño, pero el GID del proceso pertenece al grupo del archivo),
y otros (todos los demás).
Para cada categoría de usuarios, hay tres posibles permisos que se pueden conceder:
leer,
escribir y
ejecutar.
Además de estos permisos estándar, hay tres "atributos" que se pueden establecer en cualquier archivo (estos son comúnmente denominadas también permisos):
El set user ID (o SUID),
El set group ID grupo (o SGID), y
El atributo texto (o pegajoso).
SUID en un archivo
Si a cualquier clase de usuario se le concede el permiso de ejecución de un archivo, el bit SUID hace que el propietario del proceso sea el del archivo y no el usuario que ejecuta el programa. Así que si el programa intenta leer algo, los permisos que se aplican sería que el propietario del archivo y no el usuario del programa.
Por ejemplo, supongamos que el usuario Jane ejecuta el comando "vista memo.txt", y los permisos del comando vista y el memo.txt son los siguientes:
ls
-rwx--x--x 1 root bin 4515 Aug 14 13:08 vista
-rw------- 1 root bin 218 Aug 14 13:08 memo.txt
Jane tiene permiso para ejecutar vista, pero no el permiso para leer memo.txt. Así que cuando este programa intenta leer el archivo ocurrirá un error "permiso denegado".
Supongamos que cambiamos el programa para tener el bit SUID:
sudo chmod u+s vista
ls
-rws--x--x 1 root bin 4515 Aug 14 13:08 vista
Ahora, cuando Jane ejecuta este programa, el acceso a memo.txt está permitido. Cuando vista intente la lectura del archivo, el sistema no cree que Jane está tratando de leer, piensa que "root" es el usuario. Así se permite el acceso.
Una sustitución similar se produce si el bit SGID se establece y los bits de ejecución se establecen. El ID del grupo controlado no es el del usuario actual, sino del grupo del programa.
Técnicamente, cada proceso tiene un usuario real (RUID) y un grupo real (RGID). Estos son los usuarios y grupos de la persona que inició el proceso mediante la ejecución de algún programa. Cada proceso tiene un identificador de usuario efectivo euid y egid. Por defecto estos son los mismos. Sin embargo, si se ejecuta un programa que tiene el bit SUID o SGID, el UID efectivo o GID efectivo pasa a ser los del archivo, no de la persona que lo ejecuta.