Después de haber trabajado durante un tiempo con UNIX, probablemente descubres que hay mas sobre los permisos de ficheros que los bits “rwx”. Cuando examines tu sistema de ficheros verás también “s” y “t”:

$ ls -ld /usr/bin/crontab  /usr/bin/passwd  /usr/sbin/sendmail  /tmp

drwxrwxrwt   5 root   root   1024 Jan 1 17:21 /tmp
-rwsr-xr-x   1 root   root   0328 May 6 1998 /usr/bin/crontab
-r-sr-xr-x   1 root   bin     5613 Apr 27 1998 /usr/bin/passwd
-rwsr-sr-x   1 root   mail   89524 Dec 3 22:18 /usr/sbin/sendmail

Cuando ejecutes el script verás que el proceso que lo ejecuta toma tu user-ID y tu group-ID:

 user-ID efectivo:
alice
 user-ID real:
alice
 ID del grupo:
users

Cuando Tux ejecuta tu programa “idinfo” obtiene una salida similar que muestra el proceso ejecutándose ahora bajo el ID de tux. La salida del programa depende sólo del usuario que lo ejecuta y no del propietario del fichero.

Por razones de seguridad, el s-bit funciona sólo cuando se usa con binarios (código compilado) y no en scripts (una excepción son los scripts de Perl). Por lo tanto crearemos un programa en C que llamará a nuestro programa idinfo:
¿Qué son estos bits “s” y “t”?. La longitud del vector de los bits de permiso es en realidad de 4 * 3 bits. chmod 755 es solamente una abreviación de chmod 0755.

El t-bit

El t-bit (a veces conocido como “sticky bit= bit pegajoso”) es útil solo en combinación con directorios. Se utiliza con el directorio /tmp como puedes ver mas arriba.

Normalmente (sin el t-bit activado en el directorio) los ficheros pueden ser borrados si el directorio que contiene los ficheros es escribible por la persona que borra los ficheros. De esta manera, si tienes un directorio en el que nadie puede depositar ficheros, entonces nadie podrá borrar tampoco los ficheros de nadie mas.

El t-bit cambia esta regla. Con el t-bit activado, solo el propietario del fichero o el propietario del directorio pueden borrar los ficheros. El t-bit puede ser activado con chmod a+tw o chmod 1777. Aquí vemos un ejemplo:

Alice crea un directorio con el t-bit activado:

$ mkdir mytmp
chmod 1777 mytmp

ahora Bob pone un fichero en él:

$ ls -al
drwxrwxrwt   3 alice    users  1024 Jan  1 20:30 ./
-rw-r--r--  1 bob   users     0 Jan  1 20:31 f.txt

Este fichero puede ser borrado ahora por Alice (propietaria del directorio) y Bob (propietario del fichero) pero no puede ser borrado por Tux:

$whoami
tux
rm -f f.txt
rm: f.txt: Operation not permitted

S-bit activado en el usuario

Con procesos de UNIX ejecutandose bajo un “user-ID”. Esto les da acceso a todos los recursos (ficheros, etc…) a los que este usuario tendría acceso. Hay dos user-ID’s. El user-ID real y el user-ID efectivo. El user-ID efectivo es el que determina el acceso a los ficheros. Salva el siguiente script con el nombre de idinfo y hazlo ejecutable (chmod 755 idinfo).

#!/bin/sh
#idinfo: Imprime información del usuario
echo " user-ID efectivo:"
id -un
echo " user-ID real:"
id -unr
echo " ID del grupo:"
id -gn

Cuando Tux ejecuta tu programa “idinfo” obtiene una salida similar que muestra el proceso ejecutándose ahora bajo el ID de tux. La salida del programa depende sólo del usuario que lo ejecuta y no del propietario del fichero.

Por razones de seguridad, el s-bit funciona sólo cuando se usa con binarios (código compilado) y no en scripts (una excepción son los scripts de Perl). Por lo tanto crearemos un programa en C que llamará a nuestro programa idinfo:

/*suidtest.c*/
#include 
#include 
int main(){
/*Los programas seguros con SUID no deben fiarse
* de ninguna entrada de usuario o variable de entorno!! */

char *env[]={”PATH=/bin:/usr/bin”,NULL};
char prog[]=”/home/alice/idinfo”;
if (access(prog,X_OK)){
    fprintf(stderr,”ERROR: %s no ejecutablen”,prog);
    exit(1);
}
printf(”ejecutando ahora %s …n”,prog);
execle(prog,(const char*)NULL,env);
perror(”suidtest”);

return(1);
}

Compila el programa con “gcc -o suidtest -Wall suidtest.c” y activa el s-bit para el propietario:

$ chmod 4755   suidtest

o

$ chmod u+s   suidtest

¡Ejecútalo!, ¿Qué ocurre?, ¿Nada?, ¡ejecútalo desde un usuario distinto!

El fichero suidtest pertenece a alice y tiene el s-bit activado donde la x normalmente es para el propietario del fichero. Esto provoca que el fichero se ejecute bajo el user-ID efectivo del usuario al que pertenece el fichero en lugar del user-ID del que lo ejecuta. Si Tux ejecuta el programa obtendremos lo siguiente:

$ ls -l suidtest
-rwsr-xr-x   1 alice   users   4741 Jan 1 21:53 suidtest
$ whoami
tux

ejecutando ahora /home/alice/idinfo …

user-ID efectivo:
alice
user-ID real:
tux
ID del grupo:
users

Como puedes ver, esta es una característica muy potente, especialmente si el fichero con el s-bit activado pertenece a root. Cualquier usuario puede hacer entonces cosas que normalmente sólo puede hacer root. Unas palabras sobre seguridad. Cuando escribas un programa SUID debes asegurarte de que sólo puede usarse para el propósito para el cual pretendas que séa usado. Establece siempre el path (camino) a un valor absoluto. Nunca hagas que dependa de variables de entorno o de funciones que usen variables de entorno. Nunca te fíes de la entrada del usuario (ficheros de configuración, argumentos en línea de comandos…). Comprueba la entrada de usuario byte por byte y compárala con valores que consideres válidos.

Cuando un programa SUID pertenece a root, podemos establecer el user-ID efectivo y el real (con la funcion setreuid()).

Los programas Set-UID son utilizados normalmente por “root” para dar a los usuarios normales acceso a cosas que, normalmente, solo “root” puede hacer.

S-bit activado en el grupo

Los ficheros ejecutables que tienen el s-bit activado en el grupo ejecutado bajo el group-ID del propietario del fichero. Es bastante similar al s-bit para el usuario en el párrafo anterior.

Cuando activamos el s-bit en el grupo para un directorio, se asigna también el grupo para cualquier fichero que sea creado en ese directorio. Alice pertenece a 2 grupos:

$ id
uid=550(alice)  gid=100(users)  groups=100(users),6(disk)

Normalmente, los ficheros se créan para ella con el grupo asignado a “users”. Pero si se crea un directorio con el grupo asignado a “disk” y el s-bit al grupo, entonces todos los ficheros que crée alicia tendrán también el ID del grupo “disk”:

$ chmod 2775 .
$ ls -ld .
drwxrwsr-x  3 tux   disk     1024 Jan 1 23:02 .

Si alice crea ahora un fichero nuevo en este directorio, el grupo de ese directorio será “disk”

$ touch newfile
$ ls -l newfile
-rw-r--r--   1 alice    disk      0 Jan 1 23:02 newfile

Esto es interesante cuando quieres trabajar con varias personas en un equipo asegurándote de que los group-ID de los ficheros se establecen para el grupo correcto en el directorio de trabajo de ese equipo, especialmente en un entorno donde los usuarios tienen normalmente el umask a 027, lo cual hace los ficheros inaccesibles para la gente ajena al grupo.