luisa:~# cat /etc/securetty console tty1 tty2 tty3 tty4 tty5 tty6 luisa:~#Como hemos dicho, la función del anterior archivo es muy similar a la de la directiva `CONSOLE' en el fichero /etc/default/login de Solaris; si no existe, el administrador puede conectar en remoto desde cualquier lugar, mientras que si existe pero está vacío sólo se pueden alcanzar privilegios de root a través de la ejecución de `su'. En cualquier caso, el fichero no evita ni controla las conexiones remotas como superusuario a través de mecanismos como SSH o X Window, que poseen sus propios ficheros de configuración.
to-id:from-id:ACCIONdonde ACCION puede ser DENY (se deniega el cambio de identidad), NOPASS (se permite el cambio sin necesidad de ninguna clave) u OWNPASS (se solicita el password del usuario que ejecuta la orden en lugar del correspondiente al usuario al que se quiere acceder); se puede consultar la página del manual suauth(5) para conocer la sintaxis exacta del archivo. Por ejemplo, si queremos que el usuario `toni' no pueda ejecutar `su' para cambiar su identidad a `root', pero que para convertirse en `prova' sólo tenga que teclear su propia contraseña, tendremos un fichero similar al siguiente:
luisa:~# cat /etc/suauth root:toni:DENY prova:toni:OWNPASS luisa:~#Cuando toni trate de hacer `su' a las cuentas anteriores, verá algo similar a:
luisa:~$ id uid=1000(toni) gid=100(users) groups=100(users) luisa:~$ su Access to su to that account DENIED. You are not authorized to su root luisa:~$ luisa:~$ su prova Please enter your OWN password as authentication. (Enter your own password.) Password: luisa:/home/toni$ id uid=1006(prova) gid=100(users) groups=100(users) luisa:/home/toni$Es importante destacar que el contenido del fichero /etc/suauth sólo afecta a usuarios regulares, no al root: no podemos definir reglas que eviten que el administrador de un sistema cambie su identidad a cualquier usuario del mismo. Esto es algo evidente, ya que si no se permitiera al root cambiar su identidad, este no tendría más que modificar el fichero para eliminar la regla que se lo impide.
luisa:~$ su - prova
Password:
Famous, adj.:
Conspicuously miserable.
-- Ambrose Bierce
luisa:~$ ps xuw
prova 19990 0.8 0.3 1708 984 pts/8 S 07:04 0:00 -su
prova 20001 0.0 0.2 2548 908 pts/8 R 07:04 0:00 ps xuw
luisa:~$
Como vemos, en lugar del shell que el usuario esté utilizando, aparece
el nombre de programa `-su' en la última columna del listado; si la
directiva no estuviera definida sí que aparecería el nombre del shell correspondiente. Puede resultar interesante redefinir la directiva SU/SMALL>_NAME para asignarle un valor que pueda resaltar más en el listado, de
forma que el administrador pueda ver quien ha ejecutado la orden `su -'
de una forma más directa:
luisa:~# grep ^SU_NAME /etc/login.defs SU_NAME ***SU*** luisa:~# su - prova f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. luisa:~$ ps xuw USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND prova 20083 7.0 0.3 1712 988 pts/8 S 07:11 0:00 -***SU*** prova 20094 0.0 0.2 2548 912 pts/8 R 07:11 0:00 ps xuw luisa:~$A la hora de definir nuevos usuarios en el sistema también entran en juego ciertas directivas del archivo /etc/login.defs. Por ejemplo, el UID y GID máximo y mínimo para los usuarios regulares viene determinado por UID/SMALL>_MAX, GID/SMALL>_MAX, UID/SMALL>_MIN y GID/SMALL>_MIN. También existen entradas para especificar ciertas características relacionadas con las claves de los nuevos usuarios del sistema: se trata de PASS/SMALL>_MAX/SMALL>_DAYS, PASS/SMALL>_MIN/SMALL>_DAYS, PASS/SMALL>_MIN/SMALL>_LEN y PASS/SMALL>_WARN/SMALL>_AGE. Como sus nombres indican, estas directivas marcan los números máximo y mínimo de días que una contraseña puede ser usada, la longitud mínima que todo password ha de tener, y el número de días de antelación con que se avisará a los usuarios antes de que sus claves caduquen, respectivamente. Cada vez que se crea a un usuario nuevo en el sistema, se toman estos valores por defecto, aunque después es habitual particularizar para cada caso concreto.
luisa:~# for i in `awk -F: '{print $1}' /etc/passwd`
> do
> passwd -S $i
> done
root P 12/28/2000 0 -1 -1 -1
bin L 10/28/1996 0 -1 -1 -1
daemon L 10/28/1996 0 -1 -1 -1
adm L 10/28/1996 0 -1 -1 -1
lp L 10/28/1996 0 -1 -1 -1
sync L 10/28/1996 0 -1 -1 -1
shutdown L 10/28/1996 0 -1 -1 -1
halt L 10/28/1996 0 -1 -1 -1
mail L 10/28/1996 0 -1 -1 -1
news L 10/28/1996 0 -1 -1 -1
uucp L 10/28/1996 0 -1 -1 -1
operator L 10/28/1996 0 -1 -1 -1
games L 10/28/1996 0 -1 -1 -1
ftp L 10/28/1996 0 -1 -1 -1
gdm L 10/28/1996 0 -1 -1 -1
nobody L 10/28/1996 0 -1 -1 -1
toni P 12/29/2000 0 99999 7 -1
prova NP 10/23/2001 0 99999 7 -1
luisa:~#
El segundo campo de cada línea del listado anterior proporciona el estado
de la clave correspondiente: `P' si el usuario tiene contraseña, `L' si la cuenta está bloqueada, y `NP' si el usuario no tiene clave
asignada; en este último caso es muy importante poner un password al
usuario o bien bloquear su acceso:
luisa:~# passwd -S prova prova NP 10/23/2001 0 99999 7 -1 luisa:~# passwd -l prova Password changed. luisa:~# passwd -S prova prova L 10/23/2001 0 99999 7 -1 luisa:~#El resto de campos del listado hacen referencia propiedades de envejecimiento de las claves: cuando se cambió la contraseña de cada usuario por última vez, cuales son sus periodos de validez máximo y mínimo, el periodo de aviso y el periodo de inactividad antes de bloquear el acceso de forma automática; también mediante passwd (o equivalentemente mediante chage) podemos - como root - modificar esta información para cada uno de nuestros usuarios. Por ejemplo, si queremos que la clave del usuario `prova' tenga un periodo de validez máximo de un mes y mínimo de 10 días, que se avise al usuario de que su clave va a caducar con una antelación de una semana, y que si una vez la clave ha caducado el usuario no entra al sistema en cinco días se bloquee su cuenta podemos conseguirlo con la siguiente orden:
luisa:~# passwd -S prova prova L 10/23/2001 0 99999 7 -1 luisa:~# passwd -x 30 -n 10 -w 7 -i 5 prova Password changed. luisa:~# passwd -S prova prova L 10/23/2001 10 30 7 5 luisa:~#Como en este caso la cuenta está bloqueada, los cambios tendrán efecto cuando esta se desbloquee (o directamente se le asigne una nueva clave) y comience a ser utilizada; a diferencia de otros sistemas Unix, el desbloqueo de un acceso en Linux guarda una especie de estado: conserva la contraseña que el usuario tenía antes de que su cuenta fuera bloqueada.