Administración de Sistemas 
# 1  ­ ​
16 
 
 
 
Conceptos Básicos de Administración en 
Linux 
 
 
 
 
Albano González, Juan Carlos Pérez 
 
Universidad de La Laguna 
 
 
Acerca de :   
  Estas  notas  constituyen una  guía  de estudio  para los primeros temas de la asignatura 
  “Administración  de  Sistemas”.  No  se  trata  de  un  libro  de  texto  o  unos  apuntes 
completos, ni  sustituyen  a  las sesiones presenciales,  en las  que  se  utilizarán como un 
recurso  más  de  aprendizaje.  Existen  libros  muy  completos  sobre  el  tema, 
recomendados en  la bibliografía de  la asignatura. Además,  existen múltiples recursos 
en  Internet  que  son  también de gran  utilidad.  Entre  ellos,  los manuales que  publican 
digitalmente la mayor parte de las distribuciones Linux. Por ejemplo:  
[Link]
[Link]
[Link]
Estas  notas  han sido cuidadosamente elaboradas por los profesores de  la asignatura, 
pero  probablemente  no  están  libres  de  errores,  por  lo  que  si  detectas  alguno, 
rogamos nos lo comuniques para corregirlo, lo que redundará en el beneficio de todos 
los compañeros. 
 
   

 
 
 
Conceptos básicos de administración Linux 
 
 

Índice 
 
Instalación de Linux 
¿Qué es Linux? 
Discos y sistemas de archivos 
Tipos de sistemas de archivo 
Modelo UNIX y rutas de archivos 
Dispositivos y ficheros especiales 
Montaje de sistemas de archivos 
Diseño de particionamiento 
Administrador de volúmenes lógicos (LVM, Logical Volume Manager) 
Gestor de arranque 
BIOS 
UEFI 
GRUB 2 
Usuarios y recursos 
Actuando como Superusuario 
Acceso como superusuario 
Cuentas de usuario 
Creación de usuarios y fichero /etc/passwd 
Ocultación de claves: /etc/shadow 
Grupos de usuarios 
Gestión de propiedad y control de acceso a archivos 
Procesos en Linux 
Propiedad de los archivos 
Tipos de archivos 
Permisos básicos de acceso a los archivos 
Permisos especiales de archivos 
Permisos por defecto y modificación de los mismos 
Listas de Control de Acceso (ACLs ‐ Access Control Lists) 
Cuotas de disco 
Control de acceso obligatorio (MAC ‐ Mandatory Access Control) 
LDAP ‐ OpenLDAP 
Servicios de Directorio 
Breve historia 
LDAP (Lightweight Directory Access Protocol) 
Modelo de Información 
 
 
Conceptos básicos de administración Linux 
 

Modelo de nombres 
Modelo Funcional 
Modelo de Seguridad 
Delegación y replicación 
OpenLDAP 
Configuración del servidor 
Ejemplo 
NFS (Network File System) 
Configuración del servidor 
Montaje en los clientes 
Montaje automático: Autofs 
Algunas consideraciones básicas sobre la seguridad en NFS 
Ejemplo NFS y autofs 
Bibliografía 
 
 
 
   
 
 
Conceptos básicos de administración Linux 
 

 
 

1. Instalación de Linux 
 
1.1. ¿Qué es Linux? 
Linux1   es  un  sistema  operativo  (SO)   estable,  multitarea,  multiproceso,  multiplataforma  y 
multiusuario  similar  a  UNIX.  Partió  de  un  primer  desarrollo  de  un  núcleo  del SO realizado  por Linus 
Torvalds,  cuando  era  estudiante en  la  Universidad de  Helsinki 2 .  El auge  de este  sistema  fue  facilitado 
en  gran  medida  por  la  inclusión  de  herramientas  GNU3   (GNU  is  Not  Unix),  las  cuales  habían  sido 
desarrolladas  con  anterioridad  y  que  reunió  por  primera  vez  Richard  Stallman  en  1983.  Por ello,  en 
muchas ocasiones, se denomina GNU‐Linux a dicho SO. 
El  sistema  operativo  Linux  está  disponible  generalmente  en  forma  de  distribuciones4 .  Una 
distribución  Linux  es  un  conjunto  particular  de  aplicaciones,  herramientas,  utilidades,  librerías, 
documentación,  sistemas  de  ventanas,  sistema  de  gestión  de  paquetes,  etc.,  junto  con  el   núcleo 
kernel​
(​ )  de  Linux.  Una  buena  parte  de  este  software,  tanto  GNU  como  de   otras  fuentes,  suele  ser 
software  libre,  aunque  muchas  distribuciones incluyen  algún software  propietario o ciertas  partes del 
núcleo cuyo  código fuente no está disponible,  principalmente asociadas a  ​ drivers de  dispositivos. En la 
5
actualidad  existen  cientos  de  distribuciones   activas.  Unas  están  más  enfocadas  a  servidores, otras a 
seguridad, algunas a equipos de pocos recursos, a diseñadores gráficos, etc. 
 
1.2. Discos y sistemas de archivos 
filesystem​
El  término  sistema  de  archivos  (​ )  se  usa  normalmente  para  definir  dos  conceptos. 
Puede  designar  a  una  estructura  de  datos  residente  en  discos  locales  o  remotos  que  se  usa  para 
almacenar  los  archivos.  También  hace  referencia  a  la  jerarquía  de los directorios  y  los archivos en un 
disco, asignándole una estructura  lógica.  Dicha estructura, que es almacenada en los propios discos, es 
utilizada para acceder y organizar el espacio físico en ficheros y directorios,  por lo tanto, antes de poder 
utilizar una partición de disco, debe ser creada.  

1.2.1. Tipos de sistemas de archivo 

Una  de las  ventajas de Linux,  a veces visto como inconveniente por la complejidad añadida que 

supone,  es  que  soporta  una  gran  variedad  de  sistemas  de  archivos6 .  No soporta  sólo los  sistemas  de 
archivos nativos en  Linux, sino  una gran variedad de ellos utilizados en  diversos sistemas  operativos  o 
dispositivos específicos, si bien algunos de ellos son accesibles sólo para lectura y no para escritura.  
Los  sistemas  de  archivos  más  ampliamente  utilizados  actualmente  en  Linux,  algunos  por 
compatibilidad con sistemas más  antiguos,  son  ​ XFS​
ext2,  ext3,  ext4 y ​ . Los tres últimos utilizan sistemas 
7
de  journaling   (registro por diario),  que previenen inconsistencias en el sistema de archivos y aceleran 

1
 2010. What is Linux ‐ The Linux Foundation.​  ​
[Link] . 
2
 2011. Historia de Linux ‐ Wikipedia, la enciclopedia libre.​
 ​
[Link] . 
3
 Visión general del sistema GNU ‐ Proyecto GNU ‐ Free ...​  ​
[Link] . 
4
 2011. Linux distribution ‐ Wikipedia, the free encyclopedia.​  ​
[Link]
5
 2012. Search Distributions ‐ [Link]: Put the fun back ... 
[Link]
tecture=All&status=Active​ . 
6
 "File system ‐ Wikipedia, the free encyclopedia." 2011. <​ [Link] > 
7
 2011. Journaling ‐ Wikipedia, la enciclopedia libre.​
 ​
[Link] . 
 
 
Conceptos básicos de administración Linux 
 
check​
los  procesos  de  verificación  (​ ).  En  el  caso  tradicional,  cuando se  produce  un fallo  en el  sistema, 
por  ejemplo  un  fallo  de  corriente,  mientras  se  almacenan  datos  en  un  fichero,  éstos  quedarán 
corruptos  y  la  información   correspondiente  en  el  sistema  de  archivos  será inconsistente.  Para evitar 
esto,  un  sistema  de  archivos  que  usa  ​journaling  primero escribe  la información  y/o  metadatos a otra 
parte del disco, incluso  a otra partición, y anota los cambios necesarios en  un ​ log (registro). El sistema 
va  leyendo  este   registro,  aplicando  los  cambios  sobre  los  ficheros  correspondientes  y  borrando  las 
tareas  realizadas  del  registro si todo ha ido bien.  En caso de fallo, durante la posterior recuperación, el 
sistema  podrá  comprobar   y  corregir  sus  inconsistencias  de  una  manera  rápida,  analizando  las tareas 
que quedaban pendientes en el registro.  
El  sistema  de archivos ​ ext3 es una versión mejorada  de ​ ext2​, añadiendo ​ journaling​ . Además,  a 
pesar  de  tener   que  escribir  algunos  datos  más  de  una  vez,  es  más  rápido  que  su  predecesor,  pues 
optimiza  el acceso a disco.  ​ ext4 es una extensión compatible con ​ ext3​ , que puede soportar sistemas de 
archivos  de  hasta  50  TB  y  ficheros  individuales  de  hasta  16TB.  Además,  el   número  máximo  de 
sub‐directorios  pasa  de  32.000  a  más  de  65.000.  Entre   otras  mejoras,  añade  atributos  extendidos 
(xattr),  un  sistema  de  ​
journaling  para  las  cuotas   de  disco  y  aumenta  la  precisión  de  los  registros  de 
tiempo de los  ficheros  por debajo  del  segundo. Estas  últimas características también  se incluyen en el 
sistema  de  archivos  ​ XFS​ .  Se  trata  de  un  sistema  robusto  y  muy  escalable  que  soporta  ficheros  muy 
grandes  y  sistemas  de  archivos  de  hasta  100  TB.  El  número  de  archivos no  está limitado,  sólo  por el 
espacio  de  almacenamiento  disponible.  En  las  últimas  versiones  de  Linux  se  incluye  el  sistema  de 
archivos ​ Btrfs8  (B‐tree file  system), que proporciona algunas mejoras respecto a los sistemas  anteriores 
y  proporciona un modo optimizado para SSD (Solid‐State Drive). 
 

1.2.2. Modelo UNIX y rutas de archivos 

Linux,  como  UNIX,  utiliza  un  sistema  de  ficheros  jerárquico,  que  distribuye  los  ficheros  y 
directorios  formando  un  árbol.  Concretamente,  sigue  los  estándares  definidos  en  el  Filesystem 
Hierarchy  Standard  (FHS).  Los   sistemas  de  archivos  en  UNIX  están  basados  en  un  sistema  de inodos 
index  nodes​
(​ inodes​
,  or  ​ )  en   el  que  cada  fichero  posee  una  entrada  índice  almacenada  en  una  parte 
especial  del  ​
filesystem.  Los inodos contienen un sistema extensible de punteros  a los bloques reales de 
los  discos que corresponden a cada fichero, aportando la información necesaria para localizar el fichero 
en el disco. 
root​
El  comienzo  o raíz (​ ) del árbol se denota  por “/”.  La estructura concreta del árbol  depende 
de la distribución, pero suele ser similar. Un ejemplo resumido puede observarse en la siguiente figura.  

8
 2011. Btrfs ‐ Wikipedia, la enciclopedia libre.​
 ​
[Link]
. 
 
 
Conceptos básicos de administración Linux 
 
Los  nombres  de los ficheros pueden expresarse usando rutas absolutas o relativas. Supongamos 
que,  en  la  figura  anterior  existe  un  fichero   denominado “[Link]”  en el  directorio  “Documents” del 
usuario  “user1”.  Suponiendo que estamos en el directorio “/home/user1” podríamos ver su contenido, 
usando  el  comando  ​ cat  de  las  siguientes  formas,  partiendo  desde  la  raíz  (ruta  absoluta),  desde  el 
directorio actual o desde la raíz del ​ home​  del usuario: 
[user1@mypc:~] cat /home/user1/Documents/[Link] 
[user1@mypc:~] cat Documents/[Link] 
[user1@mypc:~] cat ~/Documents/[Link] 
 
Los  principales subdirectorios que se suelen encontrar “colgando” de “/” son los siguientes  (se 
describe además su contenido fundamental): 
● bin​
/​ : Binarios, programas. Pueden encontrarse también en /usr/bin. 
● sbin​
/​ : Binarios del sistema, habitualmente usados por el administrador del mismo. 
● boot​
/​ kernel​
:  Contiene  ficheros  de  arranque  y el  núcleo (​ ) de Linux.  En  algunas distribuciones 
contiene el gestor de arranque Grub (GRand Unified Boot loader) y sus ficheros asociados. 
● etc​
/​ : Variedad de programas y ficheros de configuración.  
● usr​
/​ :  Contiene  la  parte  principal  del  sistema,  donde  residen  las  aplicaciones  y  las  librerías 
básicas. Su  contenido  puede  ser  compartido por  varias  máquinas y su acceso es  de sólo lectura 
para los usuarios.  
● sys​
/​ : Datos de configuración para construir el núcleo del sistema. 
● dev​
/​ :  Se  encuentran  los  “dispositivos  lógicos”.  Los  dispositivos,  tanto  reales   conectados  al 
sistema  como  virtuales  proporcionados  por  el  ​ kernel​
,  son  representados  como  ficheros  con 
propiedades especiales.  
● home​
/​ :  Guarda  los  “directorios  de  conexión”  de  los  distintos  usuarios  del  sistema,  donde 
residen sus archivos. 
● root​
/​ : Directorio de conexión del “superusuario” (​ root​, no confundir con “/”). 
● mnt​
/​ :  Punto  de  montaje  estándar  para  sistemas  de  archivo  externos.  Los  sistemas  que  se 
montan automáticamente suelen hacerlo en ​ /media. 
● proc​
/​ :  Sistema  de  archivos  virtual  que  contiene  información  sobre  los  recursos  del  sistema: 
procesador, memoria, procesos en ejecución, etc. 
● var​
/​ :  Almacenamiento  para  los  ficheros  altamente  variables  o temporales, como  los  registros 
del sistema (​ logs​
), las colas de correo o impresión, almacenamiento temporal de descargas, etc. 

1.2.3. Dispositivos y ficheros especiales 

Un  dispositivo  de  almacenamiento  puede  ser  una  unidad  de  disco  duro  convencional  o 
magnético  (HDD),  un  disco  SSD,  un  RAID  (redundant  array  of  inexpensive/independent  disks) 
implementado  en ​ hardware​ , etc.  En general,  se trata de un dispositivo que permite el acceso aleatorio 
a los datos  a través de un procedimiento de entrada/salida por bloques (​ block I/O​
). Una partición es un 
trozo,  de  tamaño fijo, de un dispositivo de almacenamiento  y para el sistema aparece de forma similar 
a una unidad de almacenamiento independiente del resto de particiones.  
En  general,  se  puede  acceder  a  todos  los  los  dispositivos,  ya  sean  dispositivos  conectados   al 
sistema  o  dispositivos  virtuales  proporcionados  por  el  ​ kernel​,  a  través  de  ficheros  especiales 
contenidos  en  el  directorio  ​
/dev​ .  El  demonio  ​udevd ​ crea  y  elimina  los  ficheros  asociados  a  los 
dispositivos en  ​
/dev cuando es necesario. Cuando  el sistema de ficheros recibe una solicitud de acceso 
a  uno  de  estos  ficheros   de  dispositivo,  éste  pasa  la  petición  al  correspondiente  controlador  del 
device driver​
dispositivo (​ ).  
 
 
 
Conceptos básicos de administración Linux 
 

/dev​
Los ficheros de dispositivo en ​ , y sus subdirectorios, pueden ser de dos tipos: 
● character​ :  proporciona un flujo serial de  entrada  y salida, como  el usado por  ratones, teclados, 
etc. 
● block​: ofrece un acceso aleatorio, como los usados por dispositivos de almacenamiento. 
 
/dev​
Algunos ejemplos de ficheros especiales habitualmente presentes en ​  pueden ser: 

Fichero  Descripción 

/dev/hda  El dispositivo maestro de un canal IDE primario. 

/dev/hdb  El dispositivo esclavo de un canal IDE primario. 

/dev/tty0  El primer terminal virtual. 

/dev/sda  El primer dispositivo en el canal primario SCSI o SATA.  

/dev/sdb  El segundo dispositivo en el canal primario SCSI o SATA. 

/dev/lp0  El primer puerto paralelo. 
 
A  su vez,  cada una  de las  particiones de un disco  posee  un archivo de dispositivo propio, con el 
mismo  nombre   que  el  disco  al  que  pertenece pero  con número  como sufijo,  indicando  el número  de 
partición. Por  ejemplo,  si  el segundo  dispositivo SATA tuviese tres particiones, se crearían tres ficheros 
especiales denominados ​ /dev/sdb1​ /dev/sdb2 ​
, ​ /dev/sdb3​
y ​ .  

1.2.4. Montaje de sistemas de archivos 

El  montaje  de  un  sistema  de  ficheros  hace  que  su  contenido  esté  disponible  para  el  sistema 
operativo, asociándolo a  algún punto del árbol de directorios. El único sistema de archivos que  siempre 
debe permanecer montado es la raíz del árbol, que está montada en “/”. 
La  siguiente figura  muestra  un  ejemplo  de montaje de directorios  utilizando dos dispositivos de 
almacenamiento  con  dos  particiones  cada  uno.  En  la  raíz  de  árbol  de  directorios  queda  montado  el 
primer sistema de  archivos,  que corresponde  a la  primera partición del primer disco, representada por 
el fichero  especial ​
/dev/sda1​ .  La otra partición de este disco está montada en ​ /boot​ . Las particiones 
del otro disco están montadas, respectivamente, en ​ /home​ /var​
 y ​ . 
 
 
 
Conceptos básicos de administración Linux 
 

 
 
  Para montar un sistema de archivos de forma manual se puede utilizar el comando ​  de la 
mount​
siguiente forma: 
# mount [‐o opciones] <archivo especial de bloques>  <puto de montaje> 

Por ejemplo: 
# mount /dev/sdb1 /home  

Si  usamos  el  comando  sin  parámetros  u  opciones  obtenemos  un  listado  de  los  sistemas  de 
archivos que se encuentran montados en ese momento. Por ejemplo: 
# mount 
/dev/sda1 on / type ext4 (rw) 
/dev/sda2 on /boot type ext4 (rw) 
/dev/sdb1 on /home type ext4 (rw) 
/dev/sdb2 on /var type ext4 (rw) 
... 

Otros  comandos,  aunque  diseñados  para  otros  cometidos  nos  pueden  proporcionar 
información similar sobre los puntos de montaje. Por ejemplo: 
# df ‐h 
[Link]              Tamaño Usados  Disp Uso% Montado en 
/dev/sda1                 976M    32M  878M   4% / 
/dev/sda2                  93M    78M  8,8M  90% /boot 
/dev/sdb1                 976M    49M  861M   6% /home 
/dev/sdb2                 976M   907M  2,3M 100% /var 
... 

 
umount​
Para desmontar un sistema de archivos se puede utilizar el comando ​ .  
#  umount <nombre>  

donde  <nombre>  puede  ser  el  fichero  especial  asociado  al  dispositivo  o  el  directorio  en   el  que  está 
montado. Por ejemplo: 
 
 
Conceptos básicos de administración Linux 
 

# umount /home 
o 
# umount /dev/sdb1 

 
Lógicamente  el  sistema  debe  montar  de  forma  automática  durante  el  arranque  aquellas 
/etc/fstab​
unidades  que se  usan con  frecuencia. Para ello, deben declararse  en el  fichero ​ . Un ejemplo 
de dicho archivo podría ser: 
UUID=70b84d95‐756b‐4eeb‐a84d‐5b09a04f565a     /            ext4    defaults            1 1 
UUID=537cfda0‐b92c‐4b8a‐8a90‐bb45ec23e804     /boot        ext4    defaults            1 2 
/dev/hdb1                                     /home        ext4    defaults,usrquota   1 2 
/dev/hdb2                                     /var         ext4    defaults            1 3 
/dev/hdc1                                     swap         swap    defaults            0 0 
... 

Se  trata  de  un  fichero  de  texto  con  campos  separados  por  espacios  o  tabuladores.  Dichos  campos 
poseen el siguiente significado: 
● dispositivo​:  Se  trata del dispositivo de  bloque que  se quiere montar. En el ejemplo puede verse 
que  se  ha  especificado  de  dos  formas:  mediante  el  nombre  del  fichero  especial  en  ​ /devo    
mediante  su  UUID9   (universally  unique  identifier).  El  UUID   se  asigna  al  crear  el  sistema  de 
archivos  y  es  más  estable,  pues  aunque  se  cambien  los  discos  de  controladora  o  se  altere  su 
orden permanecerá igual. Los UUIDs pueden obtenerse, por ejemplo, con el comando ​ blkid​ . 
● Directorio  de  montaje​ :  en  el  que  se  montará  el  sistema  de  ficheros.  No  se  especifica  para  el 
swap ​ (espacio de intercambio10 ), ya que no estará accesible a través del árbol de directorios.  
● Tipo de sistema de archivos​ . 
● Opciones​ :  En  este  campo  se  especifican  las  opciones  deseadas,  separadas  por  comas  y  sin 
espacios.  La  posibilidades son múltiples y  deben  consultarse  para  cada sistema. En  el ejemplo, 
se  establecen  las  opciones  por  defecto  para  cada  tipo  de  sistema  de  archivos.  En  el  caso  de 
 
ext4serían  ​
rw, suid, dev, exec, auto, nouser, async​ .  Además,  para  hdb1  se 
indica que se establecen cuotas de disco aplicadas sobre los usuarios.  
● Frecuencia  de  dump​ backup​
:  Indica  la  frecuencia  con  la  que  se aplicará el  ​ , si estuviese activo, 
mediante  la herramienta ​ dump​ . 1 significa cada día, 2 cada dos días, etc. 0 indica que no se hará 
copia de respaldo de esa partición, por ejemplo para el espacio de intercambio. 
● Orden  fsck​ :  indica  el  orden  en  el  que  ​ fsck  (file  system  check)  revisa  la  consistencia  y, 
opcionalmente, repara los sistemas de archivo.  Dos sistemas en el mismo disco deberían poseer 
números de  orden distintos. Con los sistemas de ​ journaling la  complejidad  de la tarea de revisar 
las inconsistencias ha disminuido de forma notable. 
 

1.2.5. Diseño de particionamiento 

Cuando se realiza la instalación de Linux hay que  decidir de qué forma realizamos las particiones 
de  los sistemas de  almacenamiento  disponibles y  cómo diseñamos el correspondiente montaje dentro 
del árbol de directorios.  
La  utilización  de diferentes particiones o diferentes dispositivos físicos a la hora de la instalación 
tiene  diversas  ventajas,  algunas  de las  cuales pueden desprenderse de los  distintos  campos utilizados 
en  ​
/etc/fstab​ .  En  primer  lugar  podríamos  querer  utilizar  diferentes  tipos de  sistemas  de archivos, 
9
 "Universally unique identifier ‐ Wikipedia, the free encyclopedia." 2011. 
<​[Link] > 
10
 "Espacio de intercambio ‐ Wikipedia, la enciclopedia libre." 2011. <​
[Link]
> 
 
 
Conceptos básicos de administración Linux 
 

eligiendo aquel que se adapte  mejor a cada uno de los espacios de almacenamiento, ya sea por desear 
una  mayor  rapidez  de  acceso,  una  mayor  robustez,  una  mejor  adaptación  al  tipo de  dispositivo,  una 
mayor  capacidad  para  tratar  archivos  grandes,  etc. Podemos  querer limitar  el acceso a los usuarios o 
las  aplicaciones  a  una  o   unas  pocas  particiones,  de  forma que  aunque saturen  el espacio  asignado  el 
sistema  general  no  se  vea  afectado.  Además,  en   caso  de  que  una  partición  sufra  un  error  y  quede 
corrupta,  no afectaría  al resto  y  se simplificaría la posible recuperación de los datos. Si existen distintas 
particiones,  las opciones  de  montaje pueden ser diferentes, por ejemplo se puede requerir montar una 
partición  para  acceso  de  sólo  lectura  por  razones  de  seguridad. Asimismo,  podríamos desear realizar 
copias  de respaldo de  sólo alguna de las particiones y que la frecuencia de las mismas dependa del tipo 
de datos que contengan.  
La  decisión  de  las  particiones  a  realizar  depende  de  consideraciones  particulares  acerca  del 
servidor  a  instalar  y  de  algunas  consideraciones  técnicas.  Como guía  general podemos fijarnos  en las 
siguientes recomendaciones sobre las posibles particiones: 
● swap​ :  Este espacio del disco es utilizado  para almacenar temporalmente  trozos de la  memoria 
principal  que  contienen  programas  o  datos  que  no  se  usan  de  forma  continuada,  liberando  
memoria para  poder ejecutar  más  procesos  de forma concurrente. El tamaño de la partición de  
swap  depende el  uso  de la máquina, pero,  ante la duda, una  regla de oro es asignar el doble de 
la  memoria  RAM  física.  Esta  partición,  como  se  ha  comentado,  no  se  encuentra  montada  en 
ningún punto del árbol de directorios.  
● /home​ :  La  partición  o  sistema  de  almacenamiento  montado  en  este  punto  del  árbol  de 
directorios  suele  contener  los  datos  de  los  usuarios  del  sistema.  Su  tamaño  dependerá  del 
número  de  usuarios  y  de  las  necesidades  de  almacenamiento  de  los  mismos.  Al  estar 
almacenados  en  una  partición  separada,  un  posible  llenado  del  espacio  de  los  usuarios  no 
afectaría  al  resto  del  sistema,  evitando  inestabilidades  del  mismo.  Además,  permitiría  la 
limitación  de  espacio disponible a cada usuario,  a través de un sistema de cuotas, el cual es solo 
aplicable a sistemas de archivo completos. Al tratarse de datos sensibles para el funcionamiento 
de  la  empresa  puede  definirse  un  esquema   de  copias  de  seguridad  específico.  Por  la  misma 
razón,  este  punto  de  montaje suele estar relacionado  con  un sistema de  almacenamiento  que 
proporcione  redundancia  y  robustez,  como  es  el  caso  de  los   sistemas RAID11.  Asimismo, si el 
sistema  operativo  se  corrompe  o  debe  actualizarse  los  datos   de  esta  partición  no  se  verían 
afectados.   
● /  :  Debería  contener  lo  mínimo  necesario,  que  no  pueda  colocarse  en  otra  partición,  pues 
cuanto más simple sea, menos probabilidad de corrupción de datos existe. Por ejemplo, algunos 
directorios  que contienen  ficheros  de configuración  del  sistema,  ficheros  sin  los que el  sistema 
operativo no puede funcionar de  forma correcta o  que un administrador necesita para labores 
básicas e importantes (/etc, /bin, /sbin, /lib, ...), no pueden residir en otra partición.  
● /boot​ :  Pequeña  partición  que incluye las imágenes del ​ kernel ​usadas por el sistema operativo y 
los  archivos  que  necesita  el  ​ 12
system  boot  loader .  En  aquellos  sistemas   en  los  que  la 
modificación del ​ kernel es habitual se  evita  que se  llene la  partición de / con todas la versiones 
del  mismo  y  los  archivos  asociados.  Además,   en  algunos  casos  se  realiza  una  copia  de  esta 
partición para tener un respaldo en caso de problemas de arranque del sistema. 
● /usr​ :  Al  contener  multitud  de  comandos,  programas,  códigos  fuente  y  documentación, suele 
ser un directorio  de gran tamaño,  lo  que propicia colocarlo en una partición separada. Además, 
la  información  que  contiene  no  suele  modificarse  por  lo  que  en  muchas  ocasiones  prefiere 
montarse  con  accesos  de  solo  lectura,  evitando  posibles  corrupciones  en  los  datos.   A  veces 

 2011. RAID ‐ Wikipedia, the free encyclopedia.​
11
 ​
[Link]
12
 2011. Operating System Design/Initialization/Bootloader ‐ Wikibooks. 
[Link] . 
 
 
Conceptos básicos de administración Linux 
 
incluso  la  instalación  de  una  máquina  se  comparte  entre  distintos  servidores  facilitando  la 
actualización de esta parte del sistema. 
● /var​ log​
:  Al  contener  las  colas  de  impresión  o  correo,  ficheros  de  ​ ,  etc.,  puede  llenarse  con 
facilidad,  tanto  por  un  uso  correcto  como por uno  fraudulento,  así  que si se encuentra en una 
partición separada no afectaría a la estabilidad del resto del sistema.  
● /tmp​ :  Almacena  archivos  temporales  de  los  usuarios.  La  causa  para  mantenerlo  en  otra 
partición  es  similar  al  caso  anterior.  Además,  no  es  necesario  realizar  copias  de  seguridad  de 
este directorio.  
 

1.2.6.  Administrador de volúmenes lógicos (LVM, Logical Volume Manager) 

En  ocasiones  nos  damos  cuenta  que  el  diseño de  particiones  o el  espacio de almacenamiento 
asignado a cada una de ellas no es el adecuado. Por ejemplo, con el tiempo puede que una partición de 
un  disco  esté  prácticamente  vacía  cuando  la  contigua  no  disponga   de espacio libre.  Sin embargo,  las 
particiones  físicas  no  pueden  redimensionarse.  Este  problema  podría  solucionarse de  una forma más 
sencilla si usamos un administrador  de volúmenes lógicos. De esta forma,  LVM puede verse como una 
versión más  flexible  de las  particiones tradicionales. Agrupa los  dispositivos físicos de almacenamiento 
disponibles  en  “grupos  de  volúmenes”  que  luego  son  particionados  usando  diferentes  “volúmenes 
lógicos”  que  actúan   como  si  fuesen  particiones  de  disco.  Además  de  poder  redimensionar  los 
volúmenes  lógicos,  LVM  posee  otras ventajas frente  al sistema  tradicional: permite mover volúmenes 
lógicos entre diferentes  dispositivos físico,  facilita el uso de sistemas RAID, suele implementar técnicas 
de replicación de datos, etc. 
Como  los  conceptos  son  similares  a  los  mencionados  hasta  ahora  pero  con  significado  algo 
distinto, a continuación se definen los principales términos utilizados en LVM: 
● Volumen  físico.  Cualquier dispositivo de almacenamiento,  incluyendo  un  RAID,  o una partición 
del dispositivo, debe ser  inicializado  y convertido a un volumen físico para que pueda ser usado 
por LVM.   
● Grupo  de  volúmenes: Es un conjunto de volúmenes físicos que para  LVM se comportará  como 
un  único  disco, aunque  su almacenamiento  esté distribuido entre  varios dispositivos  físicos.  La 
capacidad  de  almacenamiento  de  este  grupo  de  volúmenes  es  fragmentada  en  trocitos,  o  
bloques de tamaño fijo, denominados “extensiones físicas”, normalmente de 4 MB.  
● Volumen  lógico:  Las  extensiones  físicas  de  un  grupo   de  volúmenes  pueden  agruparse  en 
diferentes  “volúmenes  lógicos”,  que  actuarán  como  si  fuesen  las  particiones  tradicionales,   es 
decir,  pueden  contener  un  sistema  de  archivos  aún  cuando   su  espacio  de  almacenamiento 
pueda  estar  repartido entre varios dispositivos físicos. Estas  “particiones  virtuales” pueden  ser 
redimensionadas, siempre siendo su tamaño un número entero de extensiones físicas.  
 
En  la  siguiente  figura   se  esquematiza  un  ejemplo  de  un  sistema  que  usa  LVM.  El  grupo  de 
volúmenes  contiene  tres  volúmenes  físicos  que  se  han  obtenido  a   partir  de  una  partición de los  dos 
primeros discos  y del tercer disco  al completo. El  espacio disponible en ese grupo de volúmenes, suma 
del espacio  de las  dos  particiones  comentadas  y  del  tercer disco,  está  dividido  en pequeños bloques o 
extensiones físicas. En el ejemplo se esquematizan dos volúmenes lógicos, cuyo tamaño es un número 
entero  de  extensiones  físicas.  En  uno  de ellos se indica que  podría  estar  montado en  “/” y el otro  en 
/home​ , como si se tratasen de particiones tradicionales. 
 
 
Conceptos básicos de administración Linux 
 

 
 
Existen  comandos que  proporcionan información  acerca de los  discos  y sobre los sistemas LVM 
disponibles en una máquina. Por ejemplo: 
# blkid 
/dev/sda1: UUID="537cfda0‐b92c‐4b8a‐8a90‐bb45ec23e804" TYPE="ext4"  
/dev/sda2: UUID="70b84d95‐756b‐4eeb‐a84d‐5b09a04f565a" TYPE="ext4"  
/dev/sda3: UUID="vAmfNk‐d6zS‐Tia1‐1do5‐XZTG‐p0U4‐ibFBRB" TYPE="LVM2_member"  
/dev/mapper/VolGroup‐swap: UUID="a63d778e‐acde‐469b‐8c3d‐ddf96b136263" TYPE="swap"  
/dev/mapper/VolGroup‐usr: UUID="0dba00fa‐bf6c‐45b7‐bf83‐5e387625cd46" TYPE="ext4"  
/dev/mapper/VolGroup‐var: UUID="bc367e4a‐dbc5‐427d‐8d00‐1fe13ce8cebc" TYPE="ext4"  
/dev/mapper/VolGroup‐home: UUID="2a26a44e‐5b48‐40e7‐af29‐5b4e3a0a2b3e" TYPE="ext4"  
 
# lsblk 
NAME              MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT 
sda                 8:0    0   15G  0 disk  
├─sda1            8:1    0  100M  0 part /boot 
├─sda2            8:2    0    1G  0 part / 
└─sda3            8:3    0 13,9G  0 part  
  ├─VolGroup‐swap 253:0    0    1G  0 lvm  [SWAP] 
  ├─VolGroup‐usr  253:1    0 10,9G  0 lvm  /usr 
  ├─VolGroup‐var  253:2    0    1G  0 lvm  /var 
  └─VolGroup‐home 253:3    0    1G  0 lvm  /home 
   ... 

En  este caso vemos que  disponemos  de un solo  disco SCSI  o SATA  que posee tres  particiones.  Las dos 

primeras  están  montadas  en  ​ /booty     “/”,  respectivamente.  La  última se  ha  definido  como volumen 
físico,  el  único  que  compone  el  grupo  de  volúmenes  “VolGroup”. En  ese  grupo de  volúmenes  se  han 
swap​
definido  4  particiones  lógicas:  la  de  ​ ,  ​
/usr​,  ​
/var y ​
/home​
. Se  puede  observar,  además,  que los 
ficheros especiales correspondientes  a los  volúmenes lógicos no se encuentran directamente en  /dev 
sino en ​ /dev/mapper​ . 
 
1.3. Gestor de arranque 
Cuando iniciamos  un sistema, lo primero que se ejecuta es un ​ firmware13  concreto, almacenado 
en  la  BIOS  (Basic  Input/Output  System)  o  en  la  UEFI  (Extensible  Firmware  Interface),  que  a  su  vez 
boot  loader​
ejecuta  el  gestor  de  arranque  (​ kernel  ​
)  encargado  de  buscar  el  ​ adecuado e iniciarlo de la 
forma  más conveniente para arrancar el sistema operativo. Actualmente, los gestores de arranque  más 

13
 "Firmware ‐ Wikipedia, la enciclopedia libre." 2011. 18 Dec. 2015 <​
[Link]
> 
 
 
Conceptos básicos de administración Linux 
 

Grand Unified Boot Loader​
utilizados en Linux son GRUB (​ ) Legacy y GRUB 2, aunque algunos otros están 
también  disponibles. Algunos fabricantes  de hardware  tienen  sus propios sistemas, pero expondremos 
los más utilizados  en ordenadores basados en arquitecturas  x86 y x86‐64. 
Tanto  el  gestor  de  arranque  como  el   ​kernel  del  sistema  operativo  estarán  ubicados  en  un 
dispositivo  de  almacenamiento,  por  lo  que  la  configuración  de  los  discos  incluye  también  configurar 
dicho gestor de forma adecuada.  

BIOS 

La  BIOS  debe  conocer  qué  dispositivo  de  arranque  ha  de  utilizar  (disco  duro,  dispositivo  usb, 
Master  Boot Record​
etc.)  y  cargar  en  memoria  el  código  contenido  en  el  MBR (​ ) de  dicho dispositivo, 
esto  es,  sus  primeros  512  bytes.  Este  código,  que  suele  ser  un  gestor  de  arranque  simple,  puede 
realizar dos acciones diferentes: 
● Examinar   la  tabla  de  particiones  del  disco  y  determinar  cuál  es  la  partición  de  arranque 
bootable partition​
(​ boot sector​
), de  donde lee  el  sector  de arranque  (​ ) que contiene un segundo 
gestor. Es este segundo gestor de arranque el que busca el ​ kernel​, lo carga y ejecuta.  

   
● kernel​
Directamente busca el ​ , lo carga y ejecuta, sin usar un segundo gestor. 

 
GRUB soporta ser instalado  tanto  en el  MBR o en  el sector  de arranque  de una partición de arranque. 
Además,  puede  controlar  el arranque de varios sistemas operativos, aunque  no  sean Linux, o distintos 
kernels​
.  
 

UEFI 
El  proceso  de  BIOS  descrito  fue  propuesto  en  los  años  1980,  por lo que tiene las  limitaciones 
inherentes a la tecnología de  aquella época. Los ​ firmwares asociados a UEFI son mucho más complejos 
y  permiten  procesos  de arranque  más  sofisticados.  UEFI busca  los gestores de arranque localizados en 
una  partición  especial denominada ESP (EFI ​ System  Partition​ ) que  usa un sistema de archivos tipo FAT 
(File   Allocation  Table).  Esto  permite  tener  diferentes  gestores  de  arranque  para  distintos  sistemas 
operativos. UEFI  tiene un gestor de arranque simple que permite decidir cuál de los gestores del ESP se 
desea.  
 
 
Conceptos básicos de administración Linux 
 

 
 

GRUB 2 

La  configuración de  GRUB  2  es  similar a  similar a la de GRUB Legacy, pero ofrece más opciones, 

al  ser  posterior, como declaraciones condicionales para modificar su comportamiento en función de las 
condiciones.  El  archivo  de  configuración  se  encuentra  en  ​ /boot/grub/[Link]  o  en 
/boot/grub2/[Link]​ . Los  distintos  sistemas  disponibles, o  los ​
kernels disponibles  se declaran en 
este fichero. Por ejemplo: 
menuentry 'CentOS Linux 7 (Core), with Linux 3.10.0‐229.el7.x86_64' ‐‐class rhel fedora … 
'gnulinux‐3.10.0‐229.el7.x86_64' { 
... 
insmod ext2 
set root='hd0,3' 
linux16 /boot/vmlinuz‐3.10.0‐229.el7.x86_64 root=UUID=cee2ff6f‐c37c‐416f‐ba83‐2bf3fd99568b ro 
crashkernel=auto [Link]=VolGroup00/LogVol01 [Link]=VolGroup00/LogVol00 rhgb quiet 
initrd16 /boot/initramfs‐3.10.0‐229.el7.x86_64.img 
... 
} 
menuentry 'CentOS Linux 7 (Core), with Linux 0‐rescue' ‐‐class rhel fedora{ 
... 
insmod ext2 
set root='hd0,3' 
linux16 /boot/vmlinuz‐0‐rescue‐27a2417f209d4e8099af2d34bbdffb25 
root=UUID=cee2ff6f‐c37c‐416f‐ba83‐2bf3fd99568b ro crashkernel=auto [Link]=VolGroup00/LogVol01 
[Link]=VolGroup00/LogVol00 rhgb quiet 
initrd16 /boot/initramfs‐0‐rescue‐[Link] 
... 
} 
 
menuentry "windows" { 
set root=(hd0,2) 
chainloader +1 
} 
 

Sin  entrar  en  detalles,  se   puede  observar  que  hay  un  sistema  Windows  instalado  en  la  segunda 
partición  del  primer  disco   y  un  sistema  operativo  Linux  en  la  tercera  partición del mismo disco.  Ésta 
tiene dos ​kernels​ disponibles, así que los dos se mostrarán en el menú de GRUB. 
Este  fichero  de  configuración  normalmente  no  se  modifica  directamente  sino  a  través  de 
algunos  ​scripts  diseñados a  tal efecto.  Los ficheros que se modifican son los contenidos en el directorio 
/etc/[Link]     el  archivo  ​
/etc/default/grub​ ,  que  son  tenidos  en  cuenta  para  la  creación  de  
[Link]​ .  Esta   reescritura  del  fichero  de  configuración  se  produce  a  veces  de  forma  automática al 
realizar  ciertas  actualizaciones, pero  puede hacerse  de forma manual  cuando se modifican los ficheros 
anteriores  mediante  ​ update‐grub  or  ​ grub‐mkconfig > /boot/grub/[Link]​ .  Además, 
existen comandos para realizar  algunas acciones directamente, por ejemplo ​ grub2‐set‐default   2
haría que la opción que la entrada del menú que arranque por defecto sea la tercera (comienza en 0).  
   
 
 
Conceptos básicos de administración Linux 
 
 

2. Usuarios y recursos 
La gestión de los usuarios y los grupos de éstos, así como la protección de los recursos del 
sistema, constituyen dos de los núcleos fundamentales de la administración de sistemas.   
 
2.1. Actuando como Superusuario 
En  Linux  existen dos tipos  de  usuarios,  los normales  y el  superusuario, también conocido como 
root  o administrador del sistema. El superusuario tiene acceso a todos los archivos y carpetas, así como 
a  todos  los  comandos  del  sistema  operativo,  por  lo  que  puede  realizar  todas  la  tareas  de 
administración.  Además,  se  suelen  crear  pseudo‐usuarios  asociados  a  ciertos  servicios  o   a  algún 
software concreto.  

2.1.1. Acceso como superusuario 

root​
Existen diferentes formas de acceder al sistema como ​ .   
La  primera  es,  simplemente,  entrar  como  ese  usuario,  con  el  ​
password  correspondiente.  Sin 
embargo,  esto  tiene  algunos  inconvenientes.  Si  existen  varios  administradores  todos  deben  usar  la 
misma  cuenta. Además, no quedan  registradas  las operaciones  que hace dicho  usuario, así  que si algo  
falla no se sabe quién accedió y qué pudo hacer.   Asimismo, el ​ password de ​ root, cuya sustracción es un 
punto  débil  de   la  seguridad  de  todo  el  sistema,  debe  ser  compartido  por  los  administradores  y 
modificado  de  forma periódica.  En cualquier  caso  el ​password  ​de cualquier  usuario y con más razón el 
de ​root​
 debe ser lo más robusto posible . 14

Para  aliviar  alguno  de los  inconvenientes anteriores, suele  utilizarse el  comando  ​ su (​

substitute 
user  identity​).  Es  un  programa  que  se  aprovecha  de  las  propiedades  de  ​ setuid​ ,  explicado  más 
adelante,  para  que  los  usuarios  puedan  realizar  tareas  habitualmente  limitadas  a  ​ root  manteniendo 
mayor control  sobre la  seguridad  del  sistema.  En  este caso tampoco se guarda un registro de cada  una 
de  las acciones de  ​ root​,  pero sí quién accedió como superusuario a través  de dicho comando y cuándo, 
lo  que puede ser almacenado  en los registros de un fichero  ​ log​
.  Normalmente se utiliza “​ su‐ ​ ” o “​
su 
‐ root​ ”, que  son equivalentes,  haciendo  que la  ​ shell se cree en modo ​ login ​
cuando se proporciona el 
password  del  superusuario,  cargando  todo  el  entorno  de  ​ root​.  En  este  caso  el  directorio  de  trabajo 
cambiará  también  al  directorio  ​ home  de  ​ root.  Los  registros  del  comando  ​  
susuelen   almacenarse  en 
/var/log/messages​
“​ ”.  El  extracto   de  algunos  de  los  registros  almacenados  al  realizar el  comando 
pueden verse en el siguiente ejemplo,  en el que se observa la hora de acceso y quién accede: 
… 
2015‐12‐21T13:13:54.425195+00:00 mypc su: (to root) manolo on pts/0 
2015‐12‐21T13:13:54.425502+00:00 mypc su: pam_unix(su‐l:session): session opened for user root by 
manolo(uid=1010) 
... 

Es una buena práctica, al igual que sucede con otros muchos comandos, utilizar la ruta completa 
al  ejecutar  ​
su​,  por  ejemplo  “/bin/​ su ‐​ ”  o  “/usr/bin/​su ‐​ ”.  Esto  proporciona  cierta  protección  
adicional  ante programas maliciosos  que puedan llamarse igual y residir en alguno de los directorios en 
los  que  busca  por  defecto  la  ​
shell  (definidos  en  la  variable  de  entorno  ​
PATH​
).  Por  la misma razón,  a 
menudo no se incluye el directorio actual “.” en dicha variable. 

14
 "Chapter 4. Hardening Your System with Tools and Services." 2014. 
<​
[Link]
ystem_with_Tools_and_Services.html#sec‐Password_Security​ > 
 
 
Conceptos básicos de administración Linux 
 
En  algunos sistemas la  cuenta de ​ root  está bloqueada y no permite  el acceso de ninguna de las 
dos formas anteriores. Aunque no se encuentre bloqueada, se aconseja acceder a través de una tercera 
vía, utilizando el comando ​ sudo (​ substitute user do​ ), también basado en el uso de ​ setuid​ .  ​
sudo toma 
como  argumento  el  contenido  de  lo   que  se   desea  ejecutar  como  ​ root  o  como  un  usuario que tenga 
acceso a  un  recurso determinado. ​ sudo consulta el fichero ​ /etc/sudoers​ , que almacena los usuarios 
que  están  autorizados  para  usar  dicho  comando  y  los  comandos  que  están  permitidos  en   cada 
máquina. Si el comando puede ejecutarse,  es decir si tuviese permisos, ​ sudo pregunta el ​ password del 
root​
propio  usuario  (no  el  de  ​ )  y  pasa  a  ejecutar  el  comando.  Dicho  ​ password  no  vuelve  a  solicitarse 
durante un tiempo,  que es  configurable. El  fichero ​ /etc/sudoers ​ debe  editarse usando el comando 
visudo​
“​ ”  ya que es un editor  que comprueba que la sintaxis de los cambios introducidos es correcta y 
guarda  una  copia  de  la  versión  anterior.  ​  
sudomantiene   un  registro  de  los  comandos  ejecutados  o 
intentados  y  toda  la  información  correspondiente.  Esa  información  puede  ser  almacenada  en  un 
archivo especificado por el administrador o decidir  que  la gestione  “​ syslog​ ”,  un demonio que recoge y 
almacena  los  mensajes  de  los  procesos  del  sistema  que  no   pertenecen  al  ​ kernel​
.  En  ocasiones  se 
configura  ​syslog para  que  envíe  los registros  a un servidor central seguro, de forma que ante cualquier 
incidencia grave se pueda averiguar lo que pudo haber sucedido y qué usuario lo ha causado.   
 
/etc/sudoers​
Se deben tener en cuenta algunos puntos al configurar ​ : 
● Las rutas a los comandos deberían ser absolutas. 
● Hay que tener cuidado que los comandos permitidos  no posibiliten invocar una ​ shell a través de 
un  proceso  hijo.  Por  ejemplo,  si  permitimos  que  alguien  acceda  al programa  “​ vi​ root​
”  como ​ , 
shell  ​
podría  teclear  “!bash”  y  accedería  a  una  ​ interactiva  como  ​
root  ya  que  el  proceso  hijo 
hereda el contexto  de seguridad  del proceso padre (explicado más adelante). Existen formas de 
evitar estos problemas, por ejemplo a través de ​ sudoedit​ .  
● Muchos  comandos  pueden  ser  peligrosos  si  se ejecutan  como ​ root​
, ya que se pueden  usar  de 
formas muy distintas a como el administrador tenía previsto.   
 
/etc/sudoers​
Un ejemplo sencillo de archivo de configuración ​  podría ser: 
User_Alias     OPERADORES = pepe, juan 
Runas_Alias    OP = root, operador 
Host_Alias     MIRED = [Link]/[Link] 
Cmnd_Alias     IMPRIMIR = /usr/sbin/lpc, /usr/bin/lprm 
 
OPERADORES ALL=ALL 
#Los operadores pueden hacer todo desde cualquier terminal. 
 
manolo ALL=(OP) ALL 
# manolo puede hacer lo que pueden hacer los miembros de OP (root y operador)  
 
carla MIRED=(ALL) ALL 
# Carla puede ejecutar cualquier comando desde cualquier terminal de la red como cualquier usuario 
 
rosa ALL= IMPRIMIR 
# Rosa puede ejecutar los comandos lpc y lprm desde cualquier máquina. 
 
marcelo ALL = (manolo) /usr/local/bin/mycommand 
# Marcelo puede ejecutar el comando indicado como si fuese manolo (sudo ‐u manolo mycommand) 
 
marta ALL = (root) /bin/vi  
# Marta puede ejecutar vi como root desde cualquier máquina 
... 

 
 
 
Conceptos básicos de administración Linux 
 
En  este  ejemplo  se  ha  incluido  uno  de  los   errores  comentados,  ya  que,  además  de  poder  acceder  a 
archivos que no debería leer,  permite a la usuaria “marta” acceder como ​ root​
 al sistema: 
[marta@mypc ̃
] sudo /bin/vi [Link] 
 ̃
 
 ̃
 
 ̃
 
… 
 ̃
 
:!bash 
[root@mypc marta] whoami 
root 

 
 
2.2. Cuentas de usuario 
 
La  gestión de los usuarios es uno de los aspectos más importantes en un  sistema Linux, tanto en 
los  servidores  como  en  los sistemas de  sobremesa, ya que  en un sistema multiusuario es necesario el 
concepto  de  propietario  de  los  objetos   del  mismo,  como  archivos,  directorios  o  procesos  que  se 
ejecuten. Por ello, desde el  punto  de vista del sistema operativo, un usuario es una entidad que puede 
poseer ficheros o ejecutar programas, independientemente de si esa cuenta de usuario está asociada a 
un usuario individual, un servicio del sistema, etc. 
 

2.2.1. Creación de usuarios y fichero ​
/etc/passwd 

El  ​
kernel  de  Linux  identifica  a  cada  usuario  por  un  número  entero,  denominado  “​ user  id”  o 
“uid”.  Sin  embargo,  las  personas  recordamos  mejor  nombres  compuestos  por  caracteres  así  que  la 
identificación  de  cada  usuario  puede  realizarse   también  a  través  de  su  nombre  de  usuario  o 
username​
“​ username  ​
”.  Para  contener  esta  información,  es  decir  los  ​ y  ​
uid  de cada  usuario, así  como 
otra  información  necesaria  sobre  el  mismo,  es  necesario  mantener  una  base  de  datos.  Esa  base  de 
datos  habitualmente no es más que  un archivo de texto plano, accesible en modo lectura por todos los 
usuarios del sistema,  denominado  ​ /etc/passwd​ . Actualmente, la gestión de usuarios individual para 
cada   ordenador  ha  sido,  en  muchos  casos,  sustituida  por  sistemas  centralizados  de  gestión  de 
identidades,  como  ​ Microsoft​
Active  Directory  (​ ),  openLDAP,  etc.  Sin  embargo,  estos  sistemas  serán 
abordados más adelante.  
Un  ejemplo  simplificado  de  fichero  ​
/etc/passwd​
,  en  el  que  se  han  eliminado  algunas 
entradas, podría ser el siguiente: 
root:x:0:0:root:/root:/bin/bash 
bin:x:1:1:bin:/bin: 
daemon:x:2:2:daemon:/sbin: 
adm:x:3:4:adm:/var/adm: 
lp:x:4:7:lp:/var/spool/lpd: 
... 
marta:x:500:500:Marta Glez:/home/marty:/bin/bash 
edmundo:x:501:501:Edmundo Perez:/home/ernie:/bin/csh 
bea:x:502:502:Beatriz Lopez:/home/betty:/bin/bash 

Cada entrada corresponde a un usuario y presenta el siguiente formato: 
username:x:UID:GID:user‐information:home‐directory:login‐shell 
donde cada campo está separado por “:”. El significado de cada uno de los campos es el siguiente: 
 
 
Conceptos básicos de administración Linux 
 

 
● username​ : también denominado  ​ login  name​ .  Es  el nombre por el que  se conoce  al usuario en  
el  sistema  y con  el que accede  al mismo. Debería ser fácil  de recordar, por lo que no debe  ser 
elegido  al  azar.  A   veces  se  usan  también  para  direcciones  de  correo  electrónico,  por  lo  que  
suelen seguir ciertos patrones que permitan identificar fácilmente al usuario. En otras ocasiones 
se  usan  nombres  diferentes  para  el  correo  electrónico  evitando  que  personas  ajenas  a  la 
organización conozcan los nombres usados para el acceso a los sistemas.  
● x:  Este  campo  está  reservado  para  almacenar  el  ​ password  del  usuario  de  forma   cifrada.  Sin 
embargo,  en  el  ejemplo  anterior se  sigue  la  recomendación de almacenar  las claves  de acceso 
en  otro  archivo (​/etc/shadow​ ),  que  se  explicará a continuación. La “x”  indica que no contiene 
el  ​
password  y  que  debe  obtenerse  de  ese  otro  archivo.  Este   campo  no  debería  estar  nunca 
vacío, pues indicaría  que el usuario  no necesita su clave para entrar, lo que constituye un grave 
problema de seguridad.  
● UID​ : número  de identificación  de usuario. Usualmente los números por debajo de 500 (1000 en 
algunas  distribuciones)  son  utilizados  para  cuentas  del  sistema,  conocidas  como 
pseudo‐usuarios.  Por definición a ​ root ​
le corresponde el ​ UID 0. No  se deberían reutilizar ​UIDs de 
usuarios  que  ya  no  existan,  al  menos  durante  un  tiempo  prudencial  hasta  eliminar 
completamente   la  información  de  los  mismos,  ya  que  los   nuevos  usuarios  podrían  acceder  a 
datos  no deseados.  Además, el  ​ UID  debería  ser único en todas las máquinas de la organización 
para el mismo usuario, con el fin de evitar problemas al compartir archivos entre ordenadores.  
● GID​ group ID. ​
:  ​ Cada  usuario tiene por  defecto  un identificador de grupo, que es considerado el 
grupo primario del mismo. Los grupos se explican en la próxima sección. 
● user‐information​ :  Contiene  información  adicional  del  usuario.  Está  compuesta  hasta  por 
cuatro campos separados por comas, usualmente el nombre completo, la dirección de trabajo, y 
los  teléfonos  de  la  oficina  y  privado.  El  usuario  puede  cambiar  su  información  usando  el 
comando ​ chfn​ . 
● home‐directory​ :  El directorio por  defecto del usuario.  El usuario  es dirigido a ese punto del 
árbol de  directorios  cuando accede al sistema. Este directorio puede estar en la misma máquina 
o  en  otra  conectada  a  través  de  la  red  actuando  como  servidor  de  datos,  lo  que  es  habitual 
cuando  se  gestionan  múltiples  usuarios.  Suele  montarse  en  ​ /home/username​ .  Si  por  alguna 
razón  el directorio del usuario  no  está  accesible, éste  es  redirigido  a un directorio por defecto, 
que suele ser la raíz, “/”.  
● login‐shell​ :  Indica  el  programa  que  será   utilizado  como  intérprete  de  comandos  para  el 
usuario.  Se inicia automáticamente al  acceder  al sistema. El  usuario puede cambiarlo mediante 
el  comando  ​ chsh ​ y  puede  elegir  cualquiera  de  los  disponibles  en  el  sistema,  que  están 
declarados en el archivo  ​ /etc/shells​ .  
 
Aunque ​/etc/passwd se trate de un archivo de texto plano no debería modificarse a mano, ya 
que un error durante  la modificación  podría crear  múltiples  problemas  en el  acceso  de los usuarios. Si 
vipw​
es  necesario modificarlo a mano al  menos debería utilizarse el editor “​ ”, basado en vi​ , pero que 
comprueba  la  sintaxis  y  posibles  inconsistencias.  En  su  lugar  deberían  utilizarse  los  comandos 
proporcionados por  el sistema para añadir, modificar o eliminar usuarios o para modificar algún campo 
concreto, como ​useradd, usermod, userdel, passwd, chage, ...  
 
 
 
Conceptos básicos de administración Linux 
 

2.2.2. Ocultación de claves:​
 /etc/shadow 

El  archivo  ​
/etc/passwd puede  ser leído por  todo  el mundo, aunque sólo modificado por ​ root​. 
Esto es así porque en  ocasiones  deben  buscarse algunos datos contenidos en  el mismo, por ejemplo al 
hacer  un  listado de los  archivos  de un directorio  el sistema mostrará  al usuario  su propietario a través 
de  su  ​
username  y  no  con  el  ​
UID  correspondiente,  por  lo  que  debe  conocer  la  equivalencia.  Otras 
aplicaciones  deben  conocer los  directorios  ​home ​ de  los usuarios  u otra información sobre los mismos. 
Este  hecho  hace  que  almacenar  los  ​ passwords  de  los  usuarios  en  ese  archivo  no   sea  aconsejable. 
Antiguamente  se  almacenaban  en  el  mismo  de  forma  cifrada,  pero  la  potencia  de  los  ordenadores 
modernos  hace  mucho  más  factible  romper  el  cifrado  y  encontrar  las  claves.  Es  por  ello  que  en  el 
campo  dedicado  a  la  clave  suela  aparecer  una  x,  indicando  que  el  ​
password   debe  buscarse  en  otro 
archivo, en  concreto en  ​ /etc/shadow​ , que también es  un archivo de  texto  plano, sólo accesible para 
root​
el ​ , y que contiene  de nuevo una línea para cada usuario, siguiendo el formato: 
username:encoded‐password:changed:minlife:maxlife:warn:inactive:expires:unused 
Por ejemplo, una línea de dicho archivo podría ser: 
marta:$6$fbzJWfo6$aduPGl9grxhhzPbVMhMbh9MDWjXD3kv1dOkodsueRXDSv9OHbAKZA6YKlOqSe5LBPEqek0t5KyrSiTwuGZ
8DK0:16474:0:60:3:2:: 

donde los campos poseen el siguiente significado: 
● username​ : es el mismo que aparece en ​ /etc/passwd​ , en el ejemplo sería “marta”.  
● encoded‐password​ :  es  donde  se  almacena  realmente  el  ​ password  del  usuario,  cifrado  con 
alguno  de  los  métodos  disponibles.  En  el  ejemplo  puede  observarse  que  el  campo 
correspondiente es bastante largo e incluye tres subcampos que comienzan por “​ $​
”. El primero 
es  el tipo de cifrado  utilizado  (1:  MD5, 2a: Blowfish,  5 SHA‐256,  6: SHA‐512),  en este caso, SHA 
de  512  bits.  El  siguiente  es  una  palabra  aleatoria  (denominada  ​ salt​
)  que  se  genera cuando el 
administrador o el usuario crean o modifican el  ​ password. El siguiente es el resultado de cifrar la 
palabra compuesta por  la clave  introducida al  crear el  ​ password más la palabra aleatoria (​ salt ​
+ 
clave).  Así  que  cuando  un  usuario  intenta  acceder  al sistema introduce su  ​ password y el  valor 
salt  es leído, ambos  se unen y se  cifran,  comparando con  la cadena almacenada.  Si coincide se 
da acceso al usuario.  
● changed​ :  Es  la  fecha en  la que  se modificó por  última vez  el password  del  usuario, expresada 
en días desde el 1 de enero de 1970. 
● minlife​ :  Es  la  vida  mínima  del  ​ password​,   esto  es,  el  número  de  días  mínimo  que  deben 
transcurrir  para  que el usuario pueda volver a cambiar  su clave.  En  el ejemplo, “marta”  puede 
cambiarlo cuantas veces quiera, pues el valor es 0. 
● maxlife​ :  Máximo número de días que se permite al usuario  mantener el  mismo  ​ password​
.  Si 
no está definido aparece el valor 99999. En el ejemplo el usuario debe cambiarlo, como mínimo, 
cada dos meses (60 días). 
● warn​:  Indica  con  cuantos  días  previos  a  la  caducidad  del  ​
password  se  notificará  este  hecho 
warning​
(​ ) al usuario. En el ejemplo, 3 días antes de que expire.  
● inactive​ : Indica cuantos días transcurrirán desde que caduca el ​ password hasta  que la cuenta 
es  bloqueada  si  no se  cambia  la clave, impidiendo el  acceso  del  usuario. En el  ejemplo,  podría 
seguir usándola dos días.  
● expires​ : Fija  la fecha,  expresada  en días desde el 1 de enero de 1970, en la que la cuenta será 
deshabilitada.  Se  usa  en  casos  en  los  que  sabemos  que  el  usuario  no  la  usará  de  forma 
permanente, como para trabajadores temporales, estudiantes que terminan sus estudios, etc. 
● unused​
: Reservado para usos futuros. Normalmente está en blanco. 
 
 
Conceptos básicos de administración Linux 
 

 
Cuando  se  desee  desactivar  una  cuenta  de  usuario  es  conveniente  no  eliminarla  durante  un 
tiempo  prudencial  por  si  hay  que  activarla  en  algún  momento  posterior.  Para  ello,  es  más  sencillo 
introducir  como  primer  carácter  de  su  ​
password  un  “*”  o  “!”  que  son  dos   símbolos  que  nunca  se 
generan   durante  el  cifrado,  por  lo  que  nunca  podrá  resolverse  correctamente.  También  puede 
modificarse  la  caducidad  de  la  contraseña,  con  lo  que  aparecería  caducada  y  no  podría  acceder  al 
sistema.  
 
2.3. Grupos de usuarios 
Los  grupos  o  conjuntos  de  usuarios  constituyen  una  de  la  piezas  fundamentales  para  la 
administración  y  la  seguridad  en  Linux.  Están  diseñados  para  agrupar  usuarios  que  tienen  intereses 
comunes  (un  mismo  proyecto,  un  mismo  departamento   o  categoría  profesional,  etc.)  de  forma  que 
puedan acceder de la misma manera a un conjunto de recursos. Al hablar de los permisos a  los recursos 
se explicará las ventajas del uso de estos grupos y sus consecuencias.  
 
Los grupos creados en el sistema también son almacenados en un fichero escrito en texto plano. 
En  concreto  se  trata  del  archivo  ​
/etc/group​
.  Un  ejemplo  de  dicho  fichero  es  el  que  se  muestra  a 
continuación:  
root:x:0:root 
bin:x:1:daemon 
daemon:x:2: 
... 
mail:x:12:postfix 
... 
marta:x:500: 
edmundo:x:501: 
... 
asesores:x:525:marta,juan,manolo 
contabilidad:x:530:bea,edmundo 
taller:x:531:juan,manolo,maria 

donde cada línea corresponde a un grupo diferente, siguiendo el formato: 
group‐name:x:GID:additional‐users 
● group‐name​ : es el nombre que identifica al grupo.  
● encoded‐password​ . Como en  el caso  de  los usuarios,  este campo  del  ​ password  no  se  utiliza, 
ya  que  se  almacena  en  un  fichero  que  sólo  puede  leer  ​root   ​
(​
/etc/gshadow​ )​
.  En  este  caso, 
aparece una “x”. 
● GID​ Group  ID​
:  Cada  grupo  requiere  un  identificador   numérico,   ​ ,  entero  no  negativo,  que  es  el 
que considera el sistema para identificarlo. 
● additional‐users​ : Se  trata de la lista de usuarios que pertenecen al grupo, identificados por 
username​
su ​  y separados por comas, sin espacios.  
 
En  el  ejemplo,  ​
marta​ ,  ​    ​
juany  
manolopertenecen   al  grupo  ​
asesores​.  También  podemos 
observar  grupos  que   no  tienen  usuarios  adicionales,  como  los  grupos  privados  de  ​
martay     de 
edmundo​ , pero la  pertenencia  de ambos a estos grupos fue declarada en el archivo ​/etc/passwd (ver 
ejemplos anteriores), donde el GID de los mismos fue indicado. 
Los  grupos  privados  para  cada   usuario,  con  el  mismo  nombre  de  ese  usuario  y  al  que  sólo 
pertenece  él,  son creados  automáticamente  por algunas  distribuciones de Linux,  como todas aquellas 
 
 
Conceptos básicos de administración Linux 
 
basadas  en Red Hat. Esto se hace por razones de seguridad ya que, como se verá más adelante, de esta 
forma  cada archivo o directorio que un  usuario cree  tendrá como grupo  propietario,  por defecto, a su 
propio grupo  privado. Además, ese grupo privado puede servir para dar permisos de acceso a través de 
él a  ciertos recursos que deben estar disponibles para el usuario, pero para los que no se desea que sea 
el propietario. En otras distribuciones se crea un único grupo, generalmente ​ users​
, y se les asigna como 
grupo por defecto, primario, a todos los usuarios. 
En cuanto a cada usuario, puede pertenecer a varios grupos. Sin  embargo, sólo uno de ellos será 
grupo  primario​
su  ​ ,  y  estará  declarado  junto  a  su  entrada  en  ​
/etc/passwd​ .  En  ​
/etc/group ​ el 
usuario  puede  aparecer  en   diferentes  grupos,  a  los  que  también  pertenecerá  y  que  se  denominan 
grupos suplementarios​ . 
Como  pasaba  en  el  caso  de  los  usuarios,  los  ​
passwords  de  los  grupos  tampoco se almacenan 
actualmente  en  el  fichero  descrito,  sino  en  un  fichero  denominado /etc/gshadow​ ,  junto  con  otra 
información de interés.  De  nuevo cada línea de este fichero se corresponde a un grupo de los definidos 
/etc/group ​
en  ​ y sigue el siguiente formato: 
group‐name:encoded‐password:group‐admins:additional‐users 
donde: 
● group‐name​ : es el nombre que identifica al grupo.  
● encoded‐password​ : es  el ​
password   cifrado para ese grupo.  Este password  sirve para  que, si 
un usuario  lo  conoce,  aunque  no  pertenezca al grupo, pueda convertir dicho grupo en  su grupo 
primario para  la  sesión  actual, por ejemplo a través del comando ​ newgrp​ . De esta forma puede 
colaborar de manera puntual con los miembros de ese grupo.  
● group‐admins​ : lista  de usuarios,  separados  por comas y sin espacios, que pueden administrar 
dicho grupo, esto es,  añadir o eliminar  usuarios,  por ejemplo con  el comando ​ gpasswd​.  No  es 
necesario  que  los  administradores  de  un  grupo  pertenezcan  al  mismo.  Está  pensado  para 
distribuir el trabajo de gestión de los grupos.  
● additional‐users​ : copia del mismo campo que aparece en ​ /etc/group​ . 
Un ejemplo de un par de entradas de un fichero de este tipo es el siguiente: 
asesores:!::marta,juan,manolo 
taller:$6$8pYeH/iZ44$[Link]/dz5c0NTlU/nPIdQ9GxUe3z89NgDMCihaQ8EH6mJH4BAyAw4G37hf
EKMMn8x.:marta:juan,manolo,maria 

password​
En  el  primero  no  hay  definido  ningún  ​ ,  ni  hay  administradores.  En  el  segundo  existe  un 
password  ​ definido,  siguiendo  el  mismo  cifrado  comentado  anteriormente  y  ​ marta​ ,  aunque  no 
pertenece al grupo, puede añadir o eliminar usuarios a “taller”.  
 
Para  la  gestión de  los grupos tampoco es conveniente modificar los archivos asociados de forma 
manual, siendo aconsejable utilizar los  comandos del sistema que permiten  crear, eliminar o modificar 
grupos,  modificar  la  pertenencia  de  usuarios  a  grupos,  etc.  Algunos  ejemplos  de  estos  comandos 
groupadd, groupdel, groupmod, gpasswd, usermod​
serían: ​ , etc. 
 
2.4. Gestión de propiedad y control de acceso a archivos 
 
Una  correcta  gestión  de  la  pertenencia  a  usuarios  y   grupos  de  los recursos del  sistema, entre 
ellos  los  archivos  y  directorios,  controlando  quién  y  de qué modo puede cada  uno  acceder a  ellos,  es 
una de las piezas  fundamentales de la administración de sistemas.  
 
 
Conceptos básicos de administración Linux 
 

2.4.1. Procesos en Linux 

El  acceso  a  los  recursos  debe  realizarse  a  través  de  procesos  que  son  ejecutados  por  los 
usuarios,  por  lo  que  se  deben  tener  algunos  conceptos  claros  respecto  a  ellos  y  su  relación  con  los 
permisos de acceso a los recursos. Un comando puede estar formado por uno o varios procesos. 
Un  proceso  lo podemos  definir como  un  programa ejecutable que está corriendo en  su propio 
espacio  de memoria.  Dichos procesos poseen  diferentes atributos, que son necesarios para su control 
por  parte  del  sistema,  los  administradores  o  los  propios  usuarios.  Dichos  atributos  pueden  ser:  un 
identificador  del  proceso  (PID),  el  PID  del  proceso  padre  (del  que  procede),  la  prioridad  para  la 
nice  number​
planificación  (​ TTY​
),  el  terminal  asociado  al mismo (​ ), y los  identificadores, real  y efectivo, 
de usuario y de grupo, etc. Es en estos últimos en los que nos debemos detener para comprender cómo 
afectan al acceso a los recursos. 
real user ID or ​
El  identificador  real  del  usuario (​ RUID​
) es el ​
UID del usuario que inicia el proceso, 
que,  como  hemos  comentado,  queda  almacenado   en  los  atributos  de dicho  proceso.  El UID efectivo 
EUID​
(​ )  es el  ​
UID  que se  emplea realmente para  comprobar si el proceso tiene acceso al recurso o no, y 
de  qué  modo.  En  la mayoría de  los casos ambos  coinciden, de  forma que  el  proceso tendrá  acceso  al  
recurso si el usuario concreto que lo lanza está autorizado para ello. Sin embargo, existen métodos que 
permiten  modificar  este  comportamiento,  como  ocurre  con  el  comando  ​ sudo,  ​ explicado 
anteriormente, o modificando los permisos de otros ejecutables, como se explicará más adelante. 
De forma  similar  el ​GID real (​RGID​ )  de un  proceso  es  el ​
GID del grupo primario del usuario que 
EGID​
lo  inicia  y  el efectivo  (​ )  el que se tiene  en  cuenta para  el acceso a los recursos.  De nuevo,  ambos 
coinciden en la mayoría de los casos pero puede modificarse ese comportamiento. 
  Además,  el proceso guarda una lista de todos los ​ GIDs de los ​
grupos  suplementario​ s a los que 
pertenece  el  usuario  que  lo  inicia,  para  comprobar   si  tiene  acceso  a  un  recurso  por  pertenecer  a 
cualquiera de dichos grupos. 
Existe  una  excepción  a  estas  reglas  que  se  refiere  a  los  procesos  que ejecuta ​ root​ .  El sistema 
distingue  dos  tipos  de  procesos:  procesos  con  privilegios  (cuyo  ​ EUID​=0)  y  procesos  sin  privilegios (el 
resto).  Para  los  procesos  con  privilegios  el  ​
kernel  del  sistema  ni  siquiera compara  los permisos de  los 
recursos  a  los  que  se  intenta  acceder,  pudiendo  acceder  a  todos  los  recursos  sin  importar  sus 
propietarios o los modos de acceso que estén permitidos para los mismos. 

2.4.2. Propiedad de los archivos 

En  Linux,  cada  archivo  o  directorio  tiene  dos  propietarios:  un  usuario  propietario  y  un  grupo 
propietario.  Además,  no  tiene  por  qué  existir  ninguna  relación  entre  ambos,  es  decir,  el  usuario 
propietario  de un archivo no tiene que pertenecer al grupo propietario del mismo. Además, el resto del 
mundo,  los  demás  usuarios,  son  conocidos  como  los  “​ otros”  (other)​.  La  razón  de  que   los  archivos 
posean  un grupo  propietario  es la de  flexibilizar  el  acceso a los mismos.  Basta con  incluir a  un usuario 
en  dicho grupo  para que  tenga  los mismos permisos de acceso que el resto de los miembros del grupo, 
o  eliminarlo  del  grupo  para  que  no  tenga  acceso  (siempre  teniendo  la  precaución  de  que  no   tenga 
acceso por pertenecer a otros grupos, los permisos estén correctamente configurados, etc.). 
ls ‐l​
Al  realizar  un  listado  detallado  de  los  archivos  de  un  directorio,  con  el  comando  “​ ” 
podemos obtener la  información de  los propietarios de  los mismos, junto  a otros datos de interés. Un 
ejemplo podría ser: 
 
 
 
Conceptos básicos de administración Linux 
 

‐rw‐rw‐r‐‐. 1 marta  taller      10  ene 14 23:26 [Link] 
d‐‐xrwxr‐x+ 2 root   asesores  4096  feb  7  2015 dir 
‐rwxr‐xr‐x. 1 juan   asesores  47976 feb  7  2015 muestra_datos 

Debemos fijarnos  en la tercera y  cuarta columnas, que corresponden  al usuario  propietario  y al grupo 

propietario,  respectivamente.  Otras  columnas,  que  aunque  importantes,  no  serán  tratadas  en 
profundidad por no estar relacionadas directamente con los temas tratados  son: la segunda, que indica 
hard  links​
el  número  de  archivos  dentro  de  un  directorio  o  el  número  de  enlaces  duros  (​ )  para  los 
archivos;  la  quinta,  que  corresponde   al  tamaño  del  archivo;  las  tres  siguientes,  que  indican  la 
fecha/hora  de  la  última  modificación;  la  última  columna,  que  muestra  el  nombre  del  fichero  o 
directorio. La primera columna se explicará con más detalle a continuación. 
  Un  detalle  importante  a  tener  en  cuenta  es  cómo  decide  el  sistema  a  quién  pertenece  un 
archivo  cuando  se  crea.  En  general,  un archivo siempre  pertenecerá al  usuario que  lo  crea  y el  grupo 
propietario  será  el  grupo  primario  de  dicho  usuario.  El  comportamiento  respecto  al grupo puede ser 
modificado,  pero   eso  se  verá  en  breve.  En  la  siguiente  secuencia  de  comandos   se  ejemplifica  el 
comportamiento habitual: 
[marta@mypc foo]$ id 
uid=511(marta) gid=519(marta) grupos=519(marta),518(asesores)  
[marta@mypc foo]$ echo "hola" > [Link] 
[marta@mypc foo]$ newgrp asesores 
[marta@mypc foo]$ id 
uid=511(marta) gid=518(asesores) grupos=519(marta),518(asesores)  
[marta@mypc foo]$ echo "algo" > [Link] 
[marta@mypc foo]$ ls ‐l 
‐rw‐rw‐r‐‐. 1 marta marta 5 ene 14 23:39 [Link] 
‐rw‐r‐‐r‐‐. 1 marta asesores 5 ene 14 23:40 [Link] 

En  este ejemplo ​ marta averigua su identidad y vemos que posee como grupo primario su propio grupo 

[Link]​
privado  y  además  pertenece  a  “asesores”.  Crea  un  archivo  (​ ).  Cambia  momentáneamente  su 
grupo  principal por asesores  (lo  puede  realizar sin un ​
password pues pertenece al mismo). Comprueba 
que  ha  surtido  efecto  el  comando  anterior   y crea un nuevo archivo de texto.  Finalmente  muestra  las 
propiedades  de ambos archivos.  En  ambos casos ella es la propietaria, ya que es quien los crea, pero el 
grupo propietario cambia, ya que al crear el segundo archivo su grupo primario era “asesores”. 
 
Aunque los  archivos  se  creen  con los propietarios  por defecto, éstos se pueden modificar. Para 
ello  se  usan  los  comandos  ​
chowny    ​
chgrp​ .  Sin embargo  no  todo el  mundo puede ejecutar  con éxito 
dichos comandos, ya que deben seguirse las siguientes reglas: 
● El usuario propietario de un archivo sólo lo puede modificar ​ root. 
● El  grupo propietario lo  puede  modificar  tanto  ​
root como el usuario propietario del archivo. Si el 
cambio lo hace este último sólo puede cambiar a otro grupo al que él pertenezca.  
 

2.4.3. Tipos de archivos 

El  tipo  de  archivo  es  especificado  por  el  primer  carácter  de  la  primera  columna  de  las 
propiedades  de  los  archivos,  cuando  las  visualizamos  mediante  el  comando  “​ ls ‐l​ ”.  Los  tipos   de 
archivos, según el código utilizado, son los siguientes: 
● ‐ :  Si está vacío (lo que se representa con el guión), se trata de un archivo normal, que puede ser 
de  texto,  ​scripts​,  imágenes,  ejecutables,  etc.  Un   ejemplo  de  las   propiedades de un fichero de 
este tipo sería:   ​ ‐rw‐r‐‐r‐‐. 1 root root 2056 ene 14 14:12 /etc/passwd 
● d : directorio. Ej.:         ​
drwxr‐xr‐x.  19 root root  3160 ene 15 12:00 /dev 
 
 
Conceptos básicos de administración Linux 
 

● l : enlace (​link​
) a otro archivo. Ej.:       ​
lrwxrwxrwx. 1 root root 7 feb 10  2015 /lib ‐> usr/lib 
● p  :  tubería  (​pipe​)  que  permite  a  dos  procesos  independientes  comunicarse   entre  sí.  Ej.: 
prw‐‐‐‐‐‐‐. 1 root root  0 ene 15 11:17 /dev/initctl 
● socket​
s  :  ​ ,  utilizado   para  realizar  conexiones  entre  dos  procesos,  residan  o  no  en  la  misma 
máquina. Ej.: ​ srw‐rw‐rw‐. 1 root root  0 ene 15 11:17 /dev/log 
● b  :  archivo  especial  asociado  a un dispositivo  de bloques,  como un disco duro, un dvd, etc. En 
este  caso  la  transferencia  de  datos  entre  memoria  y  el  dispositivo  se  realiza  de  bloque  en 
bloque. Se trata de dispositivos de accesos aleatorio. 
Ej.:    ​
brw‐rw‐‐‐‐. 1 root disk  8,   1 ene 15 11:17 sda1 

● c : archivo especial  asociado  a  un dispositivo tipo carácter, como  un  ratón, terminal, etc., en el 

que los datos se escriben o leen  de forma serial a medida que son recibidos. 
Ej.:    ​
crw‐‐w‐‐‐‐. 1 root tty  4,   0 ene 15 11:17 tty0 
 

2.4.4. Permisos básicos de acceso a los archivos  

Una  vez los  propietarios de los  archivos  han sido asignados de forma conveniente, es necesario 

permitir el acceso  adecuado  a dichos propietarios y evitar que aquellos usuarios no autorizados tengan 
acceso a  los mismos.  Es  decir, se deben fijar los “modos” de acceso, lo que se realiza  con el comando 
que  permite  cambiar  dichos  modos,  ​ chmod​ .  Dichos  permisos  o  modos  de  acceso  se  encuentran 
indicados en la  primera columna  de la información del archivo, justo después del carácter que indica el 
tipo de archivo.  
read  ‐  r​
Linux  considera  tres  tipos  de  acceso  a  los  archivos:  lectura  (​ write  ‐  w​
),  escritura  (​ )  y 
execute  ‐ x​
ejecución  (​ ) .  El efecto de estos permisos varía  dependiendo de si tratamos con un archivo  o 
un directorio. En la siguiente tabla se resume lo que permite realizar si está el permiso activo: 
 

Acceso  Fichero  Directorio 

r  Ver los contenidos  Ver los contenidos (ls) 

w  Modificar contenido del archivo  Modificar contenidos (ej.: crear, borrar o renombrar archivos) 

x  Ejecutar programas  Atravesar o entrar en el directorio  (cd) 
 
La  tripleta de permisos (rwx) es especificada para cada una de las posibles categorías de accesos 
al archivo (el usuario propietario, el grupo propietario y los “otros”) de izquierda a derecha.  Así para un 
archivo con las siguientes propiedades: 
‐rw‐r‐‐‐‐‐. 1 marta asesores 35 ene 14 23:40 [Link] 

sabemos que se trata  un fichero normal (‐), que ​
marta puede leer su contenido o modificarlo (rw‐), los 
miembros del grupo  “asesores” pueden leer el contenido pero no pueden modificarlo (r‐‐) y los “otros” 
no tienen ningún tipo de acceso permitido (‐‐‐).  
En este otro caso: 
‐r‐‐r‐x‐‐‐. 1 marta asesores 35 ene 14 23:40 modifica_bbdd.exe 

se  trata de  un archivo normal,  en concreto  un  programa ejecutable, que sólo puede ser ejecutado por 

los  miembros  del  grupo  “asesores”.  Realmente  el  permiso  de  lectura  sólo  serviría  por  si  el  usuario 
 
 
Conceptos básicos de administración Linux 
 

propietario  o  el  grupo  propietario quisieran copiarlo  (ya  que se  debe poder leer para  copiarlo en  una 

ubicación  diferente,  una  copia  “lee”  el  antiguo  y  “crea”  uno nuevo  con el  mismo  contenido). En  este 
caso  los  miembros  de  “asesores”  no  necesitarían el  permiso  de lectura  para ejecutarlo,  al  tratarse de 
un  fichero   ejecutable.  Sin  embargo,  si  se  tratase  de  un  ​
script  sería  necesario  poseer  el  permiso  de 
lectura ya que el proceso debe leerlo e interpretarlo antes de realizar las acciones contenidas en él.  
En cuanto a los directorios, funciona de forma muy similar. En este caso, el permiso “x”  significa 
atravesar (poder entrar) en el directorio. Lo más importante es recordar que un directorio es realmente 
un archivo un  tanto especial en  el que sólo se almacenan los  nombres de los archivos y subdirectorios 
que  contiene y la  información que indica  cómo encontrarlos  en el  sistema  de almacenamiento (índice 
del  inodo).  Por  lo  tanto,  si  deseamos  conocer  el  nombre  de  los  archivos  que  contiene,  sólo 
necesitaríamos  el  permiso  de  lectura  (​ r​
).  Si  además,  necesitamos  conocer  otros  atributos  de  los 
archivos  (ls  ‐l,  por  ejemplo),  necesitamos  además  el  permiso  de  ejecución  (r‐x).  Si  necesitamos 
modificar  el  contenido  del  fichero  asociado  al  directorio,  por  ejemplo  para  eliminar  un  elemento 
(eliminar  un  archivo  dentro  del  mismo),  modificarlo  (cambiar  el  nombre  a  un  archivo),  añadir  uno 
nuevo  (crear  un  archivo),  etc.,  necesitaríamos  permiso  de  escritura   (w), como para  cualquier archivo 
normal y el de ejecución (x). Este último se debe a algo similar a lo que ocurre para el “ls ‐l”, sin acceder 
al  directorio  no  se  permite  obtener  las  propiedades  de  los  archivos,  necesarias  para  todas  estas 
operaciones.  Supongamos  el  siguiente  ejemplo  en  el  que  ​ root  muestra  los  permisos  y  contenido  de 
algunos directorios: 
[root@mypc foo]# ls ‐l 
drwx‐‐x‐‐‐. 3 root   taller   4096 ene 15 22:41 mydir 
[root@mypc foo]# cd mydir 
[root@mypc mydir]# ls ‐l 
‐rw‐r‐‐r‐‐. 1 root root      5 ene 15 22:41 [Link] 
drwxrwx‐‐‐. 2 root taller 4096 ene 15 22:49 dir2 
drwxr‐‐‐‐‐. 2 root taller 4096 ene 15 23:00 dir3 
drwx‐wx‐‐‐. 2 root taller 4096 ene 15 23:16 dir4 
[root@mypc mydir]# ls ‐l dir4 
‐rw‐r‐‐r‐‐. 1 root root 5 ene 15 23:19 [Link] 

Vemos  que  existe  un directorio, llamado “​ mydir​ ”, que tiene permisos de ejecución (atravesar) para los 

miembros  del  grupo  “taller”.  Dentro  del  mismo  existen  cuatro  archivos,  uno  de  texto  y  tres 
correspondientes  a   directorios.  En  uno  de   estos  directorios,  “​ dir2​ ”,  los  usuarios  del  grupo  tienen 
todos los  permisos activos. En  el segundo,  “​ dir3​”, los  usuarios de  dicho grupo sólo tienen permiso de 
dir4​
lectura  (r).  En  el  último,  “​ ”,  tienen  permiso  de escritura y  ejecución  (wx).  Dentro de  este último 
existe  un  archivo  de  texto  (​ [Link]​ root​
)  que  pertenece  a  ​ ,  tanto  como  usuario  propietario  como  al 
grupo privado del mismo. Los “otros” sólo pueden leer el contenido de este archivo. 
Examinemos qué acciones puede realizar “juan”,  que pertenece, como veremos, al grupo “taller”: 
[juan@mypc foo]$ id 
uid=503(juan) gid=503(juan) grupos=503(juan),531(taller)  
 
[juan@mypc foo]$ ls mydir 
ls: no se puede abrir el directorio mydir: Permiso denegado 
[juan@mypc foo]$ cd mydir 
[juan@mypc mydir]$ cd dir2 
 
[juan@mypc dir2]$ cd ../../ 
[juan@mypc foo]$ echo "hola" > mydir/dir2/[Link] 
[juan@mypc foo]$ ls ‐l mydir/dir2 
‐rw‐rw‐r‐‐. 1 juan juan ene 15 22:49 [Link] 
 
[juan@mypc foo]$ cd mydir 
[juan@mypc mydir]$ ls dir3 
ls: no se puede acceder a dir3/[Link]: Permiso denegado 
[Link] 
 
 
Conceptos básicos de administración Linux 
 

[juan@mypc mydir]$ ls ‐l dir3 
ls: no se puede acceder a dir3/[Link]: Permiso denegado 
total 0 
‐????????? ? ? ? ?            ? [Link] 
 
[juan@mypc mydir]$ rm dir4/[Link] 
rm: ¿borrar el fichero regular «dir4/[Link]»  protegido contra escritura? (s/n) s 
[juan@mypc mydir] 

En  primer  lugar, “juan” comprueba su identidad, corroborando que pertenece al grupo “taller”. Intenta 

ver  el  contenido  de  “​mydir​ ”  pero  no  le  es  permitido,  porque  ni  es  ​ root  (el  propietario)  ni  el  grupo 
propietario  (al  que  sí pertenece)  tiene permisos de  lectura. Sin  embargo, sí  que puede entrar en dicho 
directorio,  ya  que  el  grupo  tiene  permiso  de  ejecución,  y  si  conociese,  de  alguna  forma,  que  existe 
dentro  un  directorio  llamado  “​ dir2​ ”  podría  entrar  en  él,  como  ocurre  en  el  ejemplo.  Vuelve  al 
directorio de  partida (​   ./../​
cd. ) y, sin necesidad de entrar en cada directorio, puede crear un archivo y 
comprobar sus propiedades  en  “​ mydir/dir2​ ”, ya que en “​ dir2​ ”  tiene todos los permisos y “​ mydir​ ” 
permite  que  lo  atraviese.  En  “​ dir3​ ”  el  grupo  sólo  tiene permiso de  lectura así  que  podrá conocer el 
nombre de los archivos, en este caso sólo contiene “[Link]”,  pero no puede averiguar sus  características. 
Por  ejemplo,  al usar “​ ls ‐l​ ”  se  observa claramente que las propiedades son sustituidas por signos de 
interrogación.   Por  último,  borra  el  archivo  “[Link]”  del  directorio  “​ dir4​ ”,  que  pertenecía  a  ​root​.  A 
veces  resulta extraño  que  pueda borrar  un archivo que no  le pertenezca, ni que tan siquiera el usuario 
esté  incluido  en  el  grupo  propietario  del archivo.  Sin embargo,  no podemos dejar de  ver  al directorio 
como  un  archivo que almacena los nombres de sus contenidos, y como el grupo “taller” tiene permisos 
“wx”  para  “​dir4​ ”,  puede  eliminar  la  entrada  correspondiente  en  dicho  archivo,  aunque  no  tenga 
permisos para leerlo ni modificarlo.  
 
Un  aspecto muy importante a  tener  en cuenta  es el  orden en  el que el  sistema  comprueba las 
credenciales del proceso que intenta acceder a un archivo y los permisos del mismo. Como se comentó, 
EUID  ​
si el ​ root​
del proceso  es igual a  0,  el de  ​ , no se comprueban los permisos, y accede sin problemas. 
En  caso  contrario  se  sigue  la  secuencia  especificada  en  el  siguiente  “pseudocódigo”,  que  tiene  en 
cuenta, por una  parte, el ​EUID ​ y  el ​
EGID  del proceso, y la lista de grupos a los que pertenece el  usuario 
que  ejecuta  dicho  proceso  y,  por  otra  parte,  los  identificadores  del  usuario  propietario  y  del  grupo 
propietario del archivo o directorio, así como los permisos correspondientes: 
EUID​
if (​  == ID del usuario propietario) { 
    Comprueba los permisos del usuario propietario ​
rwx​
rwxrwx​
; 
    Determina el acceso en función de los permisos activos. 
EGID ​
} elseif (​ o cualquiera de los IDs del  al
  istad
  eg
  ruposs
  uplementarios 
del proceso == ID del grupo propietario) { 
    Comprueba los permisos del grupo propietario ​
rwx​
rwx​
rwx​
; 
    Determina el acceso en función de los permisos activos. 
} else {  #asumiendo que no es del usuario propietario ni pertenece al 
grupo propietario 
    Comprueba los permisos de los “otros” ​
rwxrwx​
rwx​
; 
    Determina el acceso en función de los permisos activos. 
} 
De  esta  forma,  si  el  ​
EUID  coincide  con  el  ID  del  usuario  propietario  del  archivo,   se  comprueban  sus 
permisos,  y  no  se  siguen  comprobando  los  permisos  ni  del  grupo ni de  los “otros”.  Si  no coincide, se 
 
 
Conceptos básicos de administración Linux 
 

comprueba  si  el  grupo  es  coincidente  para  comprobar  los  permisos  del  grupo  propietario,  sólo  si 
tampoco coincide, se comprobará el de los otros. Lo podemos ver con un ejemplo:  
[juan@mypc ̃
]$ id 
uid=503(juan) gid=503(juan) grupos=503(juan),531(taller) 
 
 
[juan@mypc ̃
]$ ll [Link] 
‐rw‐rw‐r‐‐. 1 juan taller     19 ene 17 14:43 [Link] 
[juan@mypc ̃
]$ chmod u‐r [Link] 
[juan@mypc ̃
]$ ll [Link] 
‐‐w‐rw‐r‐‐. 1 juan taller     19 ene 17 14:43 [Link] 
[juan@mypc ̃
]$ cat [Link] 
cat: [Link]: Permiso denegado 
[juan@mypc ̃
]$ chmod g‐r [Link] 
[juan@mypc ̃
]$ ll [Link] 
‐‐w‐‐w‐r‐‐. 1 juan taller     19 ene 17 14:43 [Link] 

El  usuario  “juan”  ve  que  existe  un   archivo,  ​ [Link]​ ,  que  le  pertenece  y  también  pertenece  al 
grupo  “taller”,  del  cual  él  es  miembro.  Para comprobar lo explicado, le quita el permiso de  lectura al 
usuario  propietario  (​ chmod u‐r​ ),  esto  es,  a  él  mismo.  Cuando  intenta  mostrar  el  contenido  del 
archivo, con el comando ​ cat​ , se le deniega el permiso, aunque pertenezca a “taller” ya que, al coincidir 
el usuario, nunca se llegan a  comprobar los permisos  del  grupo. Sin embargo, los demás miembros del 
grupo  “taller” sí podrían  leer  el contenido del archivo. También  podría el resto de usuarios del sistema 
(“otros”)  .  Por  último le quita también el permiso de lectura al grupo, por lo que ni él ni nadie del grupo 
“taller”  podrían  ver  el  contenido  del  archivo.  Paradójicamente,  el  resto  de  usuarios,  los  “otros”  sí 
podrían, ya  que  llegan  hasta  el  último  “​ else​
” de  las comprobaciones al  no  ser los usuarios propietarios 
ni pertenecer al grupo propietario.   
 

2.4.5. Permisos especiales de archivos 

Además  de  los  modos  de  acceso  básicos,  explicados  en  el  apartado  anterior,  existen  otros 
modos  más  específicos,  pero  también  útiles,  para  los  administradores.  Vamos  a  dividir  los  mismos 
según se usen en archivos ejecutables o directorios.  
 
Archivos ejecutables 
En  la  actualidad,  los  únicos  permisos  especiales  que  tienen  efecto  son  ​ setUID  y  ​setGID​ . 
Recordemos  que  en  los  procesos  que  se  ejecutan  en  el  sistema,  su  ​ UID  efectivo  y  el  real,  o  el  ​
GID 
efectivo  y   el  real,  suelen  coincidir.  Sin   embargo  este  comportamiento  puede modificarse a  través  de 
estos  dos  permisos. Así, si un ejecutable tiene activo el bit ​ setUID, el ​EUID del proceso correspondiente 
no  será  igual  al  ​ RUID​
UID  del  usuario  que  lo  ejecuta,  es  decir  a  su  ​ ,  sino  al  ​
UID  del  propietario  del 
ejecutable.  De  forma  similar,  cuando un  ejecutable  tiene activo el  ​ setGID, el  proceso  correspondiente 
tendrá  el  ​EGID  igual  al  ​GID  del  grupo  propietario  del  archivo  ejecutable  y  no  al  grupo  primario  del 
usuario  que  lo  ejecuta.  De esta forma los usuarios pueden tener acceso, a través de ciertos programas, 
a recursos que de forma habitual no lo tendrían. 
Vamos a verlo con un ejemplo: 
[juan@mypc ~]$ ls ‐l /usr/bin/passwd  [root@mypc ~]# ps xao 
​asswd 
‐rwsr‐xr‐x. 1 root root 32168 ago 22  2010 p comm,ruid,euid,rgid,egid,user 
[juan@pypc ~]$ passwd   COMMAND  RUID  EUID  RGID  EGID USER 
Cambiando la contraseña del usuario alumno.  ... 
Cambiando la contraseña de alumno.  passwd  503  0    503   503 root 
(actual) contraseña de UNIX:  ... 
 
 
Conceptos básicos de administración Linux 
 

En  este  caso  el   usuario  “juan”  ejecuta  el  comando  “passwd”  para  modificar  su  ​ password  ​ (parte 
izquierda). Este  es un  ejemplo  típico en  el que se usa el ​setUID, como se muestra en la información del 
archivo  ejecutable,  donde  aparece  una  “s”  en  el  lugar  generalmente  ocupado  por   el  permiso  de 
ejecución  (x)  para  el  usuario  propietario.  La razón  de usar  este permiso  es  que  los  usuarios  no tienen 
acceso  a   la  modificación  directa  de  los  ficheros   ​
/etc/passwdy    ​
/etc/shadow​ ,  pero  sí  pueden 
cambiar  ciertos  campos  de  los  mismos.  Lo  realizan  a  través  de  estos  programas  pues  cuando  se 
ejecutan  toman el ​ EUID=0​ , es decir,  actúan  como si lo hubiese ejecutado ​ root, que no tiene problemas 
para  realizar  las  modificaciones.  Los  comandos  están  programados  para  que  se  modifique  sólo  la 
información del usuario que los ejecuta y no tenga acceso al resto de la información. Como el programa 
se  queda  esperando  a  datos  que  debe  suministrar  el  usuario,  ​ root  aprovecha  ese  momento  (parte 
derecha) para averiguar  los procesos que  están corriendo, solicitando los parámetros indicados. Puede 
verse  que para el proceso correspondiente  al  comando  ejecutado  por “juan”,  el ​ RUID ​ es el del propio 
“juan” (503) pero el efectivo corresponde a ​ root​ EUID​
 (​ =0). 
 
setGID​
De forma similar, podemos ejemplificar el comportamiento de ​ : 
[juan@mypc ~]$ id   
uid=503(juan) gid=503(juan)   
grupos=503(juan),531(taller)   
[juan@mypc ~]$ ls ‐l pulsa_tecla   
‐rwxrwxr‐x. 1 juan juan 6694 ene 18 12:52 pulsa_tecla   
[juan@pypc ~]$ ./pulsa_tecla    
Pulsa una tecla:  [root@mypc ~]# ps xao 
  comm,ruid,euid,rgid,egid,user 
  COMMAND  RUID  EUID  RGID  EGID USER 
  …  
  pulsa_tecla  503    503  503   503   juan 
  … 
  [root@as10 juan]# chgrp contabilidad pulsa_tecla  
  [root@as10 juan]# chmod g+s pulsa_tecla 
  [root@as10 juan]# ls ‐l pulsa_tecla 
  ‐rwxrwsr‐x. 1 alumno contabilidad 6694 ... 
  pulsa_tecla 
   
   
[juan@pypc ~]$ ./pulsa_tecla    
Pulsa una tecla:  [root@mypc ~]# ps xao 
comm,ruid,euid,rgid,egid,user 
COMMAND  RUID  EUID  RGID  EGID USER 
…  
pulsa_tecla  503    503  503   530   juan 
… 
[root@mypc ~]# grep contabilidad /etc/group 
contabilidad:x:530:bea,edmundo 

En  este caso “juan” ejecuta un  programa que le  pertenece, es su propietario y el grupo propietario es 

su  grupo  privado.  Cuando  el  programa queda  en espera de la  pulsación de  una tecla,  el superusuario 
lista los procesos con la información solicitada.  Podemos ver que en este caso los ​ UID y ​GID efectivos y 
reales  coinciden  y  son  iguales  al  ​
UID  de  juan  y  al  de  su  grupo  privado.  Luego,  ​
root  cambia  el  grupo 
propietario  del  ejecutable  a “contabilidad” y activa  el bit  ​ setGID​, lo que  comprueba a continuación. El  
usuario  vuelve  a  ejecutar  el  programa  y  ahora  ​ root  (podría  ser  el  mismo  usuario  en  otro  terminal)  
visualiza que  el ​
GID efectivo corresponde al del grupo propietario del archivo ejecutable, no al primario 
de “juan",  lo que comprueba con el último comando.  
Hay algunos  aspectos  básicos a tener en cuenta. Como el uso del ​ setUID suele comportar que el 
proceso  tome  la identidad efectiva  de otro  usuario, en  muchas  ocasiones  ​ root​, hay que ser  cuidadoso 
en  la programación de los  comandos  y evitar los fallos de seguridad. Suele ser más seguro crear grupos 
setGID​
para  operaciones  específicas  y  utilizar  ​ .  También  hay  que  considerar  que  si  un programa tiene 
 
 
Conceptos básicos de administración Linux 
 

fork ​
uno  de  estos dos permisos  activos y durante su  ejecución hace  uso  de la  llamada al sistema ​ para 
generar un  proceso  hijo, éste no hereda los ​
UID y ​
GID efectivos del padre, y volverán a coincidir con los 
shell script​
reales.  Esto ocurre por  ejemplo  cuando  ejecutamos un  ​ , siendo un error común intentar que 
los usuarios accedan a determinados recursos activando ​ setUID ​ setGID​
o ​  en los mismos. 
Debemos fijarnos  también que  cuando  observamos  las propiedades  de un archivo los permisos 
setUID  ​
y ​setGID ocupan los mismos lugares  de los permisos de ejecución para el usuario propietario y el 
grupo  propietario, respectivamente. Por ello, para poder saber si el permiso de ejecución está activo se 
utilizan  las letras  mayúscula y minúscula. Esto es,  si aparece “s” indica que ambos están activos, tanto x 
como s. Si aparece “S”, el permiso de ejecución no está activo. 
 
Directorios 
sticky  bit​
El  primero  de  los  permisos  especiales  en  directorios  es  el  ​ ,  ​
conocido también por  su 
nombre formal: ​ save text  mode,  y  representado  por la letra  “​t​
”.  En  este caso  al  activar  el ​
sticky  bit en 
un  directorio  hace  que  sólo  el  propietario  de  un  archivo  contenido  en  el  mismo  esté  autorizado  a 
borrarlo,  independientemente  de  los  permisos  que  tenga  el  directorio.  Un  ejemplo  típico  es  el 
siguiente: 
drwxrwxrwt. 18 root root 4096 ene 17 14:52 /tmp 
En  el  directorio  temporal,  aunque  pertenezca  a  ​ root​,  todos  los  usuarios  (“otros”)  tienen  todos  los 
permisos  activos (rwx).  Sabemos que la ejecución, o acceso al directorio, está activa pues la la letra que 
sticky  bit​
indica  el  ​ ,  y  que  ocupa   su  mismo  lugar,  es  minúscula  (t).  Si  fuese  mayúscula  (T)  no  estaría 
activa  la  ejecución.  En  principio,  como  están  activados  los  permisos  “wx”  cualquier  usuario  podría 
crear, borrar o  renombrar archivos en su interior.  Sin embargo, al estar el ​ sticky bit​
,  cuando un usuario 
intenta  borrar un archivo de su interior  el sistema comprueba  que coincide  con el  usuario propietario 
del mismo y  en caso contrario no permite tal operación.   
 
El  otro  permiso  especial  para  directorios  es  el  ​setGID​.  Si  este  permiso  está  activo  en  un 
directorio  todos  los  archivos  que  se  creen  dentro  de  él  tendrán  como  grupo   propietario  al  grupo 
propietario  del  directorio y  no  al  grupo primario del usuario  que lo crea, como  es habitual. Esto es así 
para permitir compartir información con el resto de usuarios del grupo propietario del directorio.  
Por ejemplo: 
[juan@mypc ~]$ id 
uid=503(juan) gid=503(juan) grupos=503(juan),531(taller) 
[juan@mypc ~]$ echo "hola" > [Link] 
[juan@mypc ~]$ ls ‐l 
‐rw‐rw‐r‐‐. 1 juan juan      5 ene 18 14:51 [Link] 
drwxrwsr‐x. 2 root   taller 4096 ene 18 14:46 dirS 
[juan@mypc ~]$ cd dirS/ 
[juan@mypc dirS]$ echo "hola" > [Link] 
[juan@mypc dirS]$ls ‐l 
‐rw‐rw‐r‐‐. 1 juan taller 5 ene 18 14:54 [Link] 

El  usuario “juan” crea un  fichero en  su  directorio “home” y,  como es normal, este nuevo archivo toma 

como  usuario propietario a su  creador y como  grupo propietario al  primario de  dicho creador, en este 
caso  su  grupo  privado. Al  realizar el  listado, puede observarse  que además existe un directorio  con  el 
setGID  ​activado.  Entra  en él  y  vuelve a crear  un archivo. Ahora, el grupo ya no es el privado de “juan” 
sino el  grupo propietario del directorio “​ dirS​ ”.  Si  crease un  directorio  dentro  de él, además de tener 
como  grupo propietario a “taller”, heredaría el  ​ setGID para que, a su vez, lo que se crease dentro de él 
también fuese compartido por el grupo. Por ejemplo:  
 
 
Conceptos básicos de administración Linux 
 

[juan@mypc dirS]$ mkdir Dir2 
[juan@mypc dirS]$ ls ‐ld Dir2/ 
drwxrwsr‐x. 2 juan taller 4096 ene 19 11:23 Dir2/ 

2.4.6. Permisos por defecto y modificación de los mismos 

En  los  ejemplos  anteriores  hemos  visto  que  los  archivos  y  directorios  se  crean  con  unos 
permisos  o  modos  de  acceso  determinados,  luego  veremos  la  razón,  pero  antes  veamos   cómo 
modificarlos.  El comando utilizado para ello es ​
chmod​   change mode​
(​ ). No trataremos a fondo el uso de 
este  comando  ya  que  está  recogido  en   multitud  de  libros,  manuales  y  en  la  propia  ayuda  de  Linux 
(comando ​ man​ ), sólo realizaremos  una breve introducción.  Existen dos formas básicas de modificar los 
permisos.  La  primera  es  utilizando  una  cadena  con  los  modos  que  se  desean  cambiar,  siguiendo  el 
esquema siguiente: 
 

Quién accede  Operador   Modo de acceso 

Uno o más de los siguientes,    r 
separados por comas y sin espacio  +​
 (añade nuevo permiso)  w 
u ​
(usuario prop.)  ‐​
 (elimina el permiso)  x 
g ​
(grupo prop.)  =​(fija exactamente ese  s 
o ​
(otros)  permiso)  t 
a ​
(todos)   
  
Veamos algunos ejemplos: 
[marta@mypc ~]$ echo "hola" > [Link] 
[marta@mypc ~]$ ls ‐l [Link] 
‐rw‐rw‐r‐‐. 1 marta marta 5 ene 18 20:10 [Link] 
[marta@mypc ~]$ chmod u=r,g‐w [Link] 
[marta@mypc ~]$ ls ‐l [Link] 
‐r‐‐r‐‐r‐‐. 1 marta marta 5 ene 18 20:10 [Link] 
[marta@mypc ~]$ chmod a+w,g+s,+t [Link] 
[marta@mypc ~]$ ls ‐l [Link] 
‐rw‐rwSrwT. 1 marta marta 5 ene 18 20:10 [Link] 

Se  han  especificado  permisos,  se  han  eliminado  y  añadido,  incluyendo  permisos  especiales,  aunque 
setGID​
para un archivo de texto ni ​ sticky bit​
 ni el ​  tienen significado alguno. 
 
Los  permisos también se  pueden especificar  de forma numérica,  en binario,  tomando cada  una 
de las tripletas por separado. Podemos tener en cuenta el siguiente esquema: 

especiales  usuario propietario  grupo propietario  otros 

setUID  setGID  sticky  r  w  x  r  w  x  r  w  x 

2  1  0  2  1  0  2  1  0  2  1  0 
2​ 2​ 2​ 2​ 2​ 2​ 2​ 2​ 2​ 2​ 2​ 2​

4  2  1  4  2  1  4  2  1  4  2  1 
Los  permisos especiales  no  es  necesario especificarlos, si se indican sólo tres cifras se entiende que son 
los permisos “ugo”. 
 
 
Conceptos básicos de administración Linux 
 

En  el  siguiente  ejemplo  se  realiza  exactamente  lo  mismo  que   en  el   anterior,  pero  de  forma 
numérica: 
[marta@mypc ~]$ echo "hola" > [Link] 
[marta@mypc ~]$ ls ‐l [Link]  
‐rw‐rw‐r‐‐. 1 marta marta 5 ene 18 20:26 [Link] 
[marta@mypc ~]$ chmod 444 [Link] 
[marta@mypc ~]$ ls ‐l [Link]  
‐r‐‐r‐‐r‐‐. 1 marta marta 5 ene 18 20:26 [Link] 
[marta@mypc ~]$ chmod 3666 [Link] 
[marta@mypc ~]$ ls ‐l [Link]  
‐rw‐rwSrwT. 1 marta marta 5 ene 18 20:26 [Link] 

Vemos  que  con el primer  comando  ​ chmod ​ lo  que  pretendemos es activar sólo los permisos de lectura 

para  todos.  El  permiso  de  lectura  corresponde  con  el  4,  así  que   los  permisos  totales  (sin  contar  los 
especiales)  son  444.  En  la  segunda  ocasión, pretendemos  que todos tengan  los permisos rw, es  decir 
4+2=6 y activar los bits de ​ setGID​ sticky bit​
 y el ​  (2+1=3), por lo que los permisos totales son 3666. 
En  los  ejemplos  anteriores,  al  crear  el  fichero  éste  contiene  unos permisos  por defecto. Estos 
permisos  vienen  fijados  por  la  ​ user  mask  (​ umask​ ).  ​
root  puede  especificar  la  ​
umask    por  defecto, 
usualmente  en  ​ /etc/profile​ .  Luego,  el  usuario  puede  modificarla  en  sus  propios  archivos  de 
configuración o mediante  el comando ​ umask​ . En este último caso, esta propiedad afecta  a los archivos 
creados  por  el  usuario  en  la  sesión  actual,  independientemente  del  directorio  en  el  que se  creen los 
archivos. Este  comando  sirve también  para averiguar la máscara por defecto, tanto de forma numérica 
como simbólica. Por ejemplo:  
[marta@mypc ~]$ umask 
0002 
[marta@mypc ~]$ umask ‐S 
u=rwx,g=rwx,o=rx 

En  el  caso  del  resultado  numérico  la  primera  cifra  es  igual  a  0,  e  indica  que  está  en  notación  octal. 
Consideraremos  los  tres  restantes,  que  indican  los  permisos  “ugo”   que  deben  eliminarse!  Esto  es,  al 
tener  una  máscara  002,  al  usuario  propietario  no  se  le  elimina  ninguno,  al  grupo  tampoco  y  a  los 
1​
“otros”  el  2=2​ ,  el  de  escritura.  Cuando  se  muestran  los  permisos  de  forma  simbólica  aparecen 
directamente los permisos que aparecerían, no los que se eliminan.  
Vamos a ver un ejemplo de cambio de máscara y sus efectos: 
[marta@mypc ~]$ umask 
0002 
[marta@mypc ~]$ touch [Link] 
[marta@mypc ~]$ mkdir dirA 
[marta@mypc ~]$ umask 067 
[marta@mypc ~]$ touch [Link] 
[marta@mypc ~]$ mkdir dirB 
[marta@mypc ~]$ ls ‐l 
total 8 
‐rw‐rw‐r‐‐. 1 marta marta    0 ene 18 23:28 [Link] 
‐rw‐‐‐‐‐‐‐. 1 marta marta    0 ene 18 23:29 [Link] 
drwxrwxr‐x. 2 marta marta 4096 ene 18 23:29 dirA 
drwx‐‐x‐‐‐. 2 marta marta 4096 ene 18 23:29 dirB 

Sin  cambiar la  máscara (002) se crea un archivo  y un  directorio, a los que sólo se les elimina el permiso 

de  escritura a  los “otros”.  Puede  verse  que, aunque  no lo elimina la  máscara, el  permiso  de ejecución 
no  se asigna  por defecto  a  los  archivos,  que  se  suponen no ejecutables, pero  sí  a los  directorios,  a los 
que  se  supone  se  desea  acceder.  Luego  se  cambia  la  máscara  067,  es  decir  no  se  elimina  ningún 
permiso para  el usuario propietario, se elimina la lectura y escritura (4+2=6) para el grupo propietario y 
se eliminan todos (4+2+1=7) para el resto. 
 
 
Conceptos básicos de administración Linux 
 

2.4.7. Listas de Control de Acceso (ACLs ‐ Access Control Lists)  

Hasta ahora hemos  visto los permisos tradicionales de Linux, que son bastante útiles y permiten 
controlar  los  accesos  a  los  recursos.  Sin  embargo,  en  muchas  ocasiones poder clasificar  los permisos 
sólo  en  tres  tipos  (usuario propietario, grupo  propietario  y “otros”) no ofrece  la suficiente flexibilidad 
para  las  situaciones  que  podemos  encontrarnos.  Por  ejemplo,  si  los  miembros de  un  grupo deberían 
poder  modificar  el  contenido  de   un  archivo,  los  de  otro  grupo  deberían  poder  leerlo  y  el  resto  no 
debería tener acceso alguno, los  permisos “ugo” no son suficientes, ya que no hay forma de especificar 
un modo de  acceso diferente  para dos grupos  de usuarios. Otros sistemas operativos, como Windows, 
son  mucho más flexibles y  permiten  muchos  más  tipos  de permisos, que los  implementan  a través de 
listas de  control de  acceso.  En  ese caso, cada  archivo o  directorio  posee  una lista  de modos de acceso 
que contienen  múltiples  entradas (ACEs ‐ Access  Control Entries). Cada una de estas entradas identifica 
a un  usuario o  a un grupo  e  indica qué permisos tiene sobre el recurso.  Cada archivo  tiene un límite de 
entradas,  pero  suele  ser  suficiente para  los propósitos generales. Además  de la necesidad una mayor 
flexibilidad,  las  ACLs  han  sido  introducidas  en  Linux  para  permitir  una  mayor  interoperabilidad  con 
otros sistemas que sí las usaban.  
Las ACLs  en Linux no sustituyen  a los  permisos  “ugo”  sino que “conviven”  con ellos, por lo que 
también  hay  que  tenerlos  presentes.  De  hecho,  si  usamos  el  comando  ​  
getfaclpara   consultar  las 
ACEs  de  un  archivo,  aunque  para  él  sólo  se  hayan  definido  los permisos tradicionales,  devolverá los 
mismos en el formato ACL, por ejemplo: 
[marta@mypc ~]$ ls ‐l [Link] 
‐rw‐rw‐r‐‐ 1 marta asesores 10 ene 24  2014 borra 
[marta@mypc ~]$ getfacl [Link] 
# file: [Link] 
# owner: albano 
# group: asesores 
user::rw‐ 
group::rw‐ 
other::r‐‐ 

Vemos  que  la información  es exactamente  la misma en  ambos casos, aunque representada de distinta 

forma.  
El  ejemplo anterior  permite hacerse  una idea sobre  cómo son las  ACEs  en Linux. Cada  entrada 
user​
puede  hacer   referencia  a  un  usuario  (​ group​
),  a  un grupo (​ others​
) o  a  los  “otros” (​ ). En general el 
formato sería: 
user:<username>:<permisos> 
group:<groupname>:<permisos> 
donde  el  nombre  del  usuario  o  el  del  grupo  pueden  ser  sustituidos  también  por  el  ​ GID​
UID  o  ​ , 
respectivamente.  Los  permisos  son  los  habituales  r,w  y  x.  En   el  ejemplo  previo  no  aparece  ningún 
nombre entre los  dos  puntos, pues si no se especifica se asume que corresponden al usuario o al grupo 
propietario, cuya información también es ofrecida por el comando. 
En  general,  con  el  comando  setfacl  pueden  especificarse  nuevas  entradas  en  la  ACL.   Por 
ejemplo: 
 
 
[marta@mypc ~]$ setfacl ‐m u:juan:rw [Link] 
[marta@mypc ~]$ setfacl ‐m g:taller:r [Link] 
[marta@mypc ~]$ ls ‐l [Link] 
‐rw‐rw‐r‐‐+ 1 marta asesores 10 ene 19 14:59 [Link] 
 
 
Conceptos básicos de administración Linux 
 

[marta@mypc ~]$ getfacl [Link] 
 
# file: [Link] 
# owner: marta 
# group: asesores 
user::rw‐ 
user:juan:rw‐ 
group::r‐‐ 
group:taller:r‐‐ 
mask::rw‐ 
other::r‐‐ 

donde vemos  que, además de  los  permisos existentes anteriormente,  se  ha  añadido un nuevo usuario 

con  permiso  de  lectura  y  escritura y  otro grupo  con permisos  de lectura.  Además,  podemos  observar 
que aparece una nueva entrada, correspondiente a la máscara (​ mask​ ) que indica los permisos máximos  
de  todos  los  grupos  y  usuarios  sin   incluir  al  usuario  propietario  y  los  “otros”.  Esta máscara,  en este 
caso,  no la  hemos especificado nosotros, sino que el sistema la ha calculado en  base a los permisos que 
hemos fijado. Sin  embargo, podría especificarse concretamente la máscara que deseamos, por ejemplo 
si la  fijamos como  “r‐‐”, aunque  los usuarios  y  grupos  afectados tuviesen más  permisos (rw‐ o rwx) no 
se  les  aplicarían,  pues  ​
mask  fija  un  máximo  a  los  permisos  a  aplicar.  Este  comportamiento  puede 
introducir  una  cierta  flexibilidad  en  ocasiones  muy  concretas  en  las  que,  por  ejemplo,  se  desee 
restringir  el  acceso  momentáneamente  a  los usuario  o grupos,  pero complica la  administración.  Si  de 
forma permanente se desea restringir el acceso, deberían fijarse correctamente los permisos a grupos y 
usuarios directamente.   
Como  en  el  caso  de  los  permisos  “ugo”,  y  al  convivir  con  los  mismos,  es  necesario  tener  en 
cuenta  cómo  se  analizarán  los  permisos  de  las  ACLs  para  permitir  el  acceso  a  los  recursos.  El 
pseudocódigo  del  algoritmo  que  se  sigue  para  determinar  si un proceso  tiene acceso al recurso es  el 
siguiente: 
 ​ EUID​
if (​  == ID del usuario propietario) { 
‐Comprueba los permisos del usuario propietario user::???; 
‐Determina acceso en función de los permisos activos. 
}  
EUID​
elseif (​  == ID de cualquier usuario, ****, declarado en la ACL) { 
‐Comprueba los permisos del usuario adicional coincidente, user:*****:???; 
  ‐Determina el acceso en función de los permisos activos para ese usuario, 
mask​
descartando los que no estén activos en la máscara (​ ). 
}  
EGID ​
elseif (​ o cualquiera de los IDs de la lista de grupos suplementarios del proceso 
== ID del grupo propietario o ID de cualquier grupo declarado en la ACL) { 
‐Comprueba los permisos de todos los grupos adicionales (ACL) que  
coincidan, group:*****:???; 
  ‐Determina el acceso en función de los permisos activos para cada grupo, 
mask​
descartando los que no estén activos en la máscara (​ ). 
}  
else {   
  ‐Comprueba los permisos de los “otros o::???; 
  ‐Determina acceso en función de los permisos activos. 
} 
 
 
 
Conceptos básicos de administración Linux 
 

Podemos  ver  que  es  similar  a  los  permisos  tradicionales,  teniendo  en  cuenta que hay  nuevos 
usuarios  y  grupos  y  que  entra  en  juego  el  papel  de  la   máscara.  Una  situación  por  la  que  cabría 
preguntarse  es,  qué pasaría cuando un usuario que, mediante un proceso, intenta acceder a un recurso 
pertenece  a  varios  de  los  grupos  que  están  dados  de  alta  en  la  ACL  del  mismo. En algunos  sistemas 
operativos  los  permisos  se  suman,  permitiendo  al  proceso  el  acceso  más  favorable. Sin  embargo, en 
Linux el permiso debe entenderse por cada grupo individual. Veamos un ejemplo: 
[eva@mypc ~]$ id 
uid=500(eva) gid=500(eva) grupos=500(eva),514(eventos),515(marketing) 
[eva@mypc ~]$ getfacl MyDir/ 
# file: MyDir/ 
# owner: root 
# group: root 
user::rwx 
group::r‐x 
group:eventos:r‐x 
group:marketing:rw‐ 
mask::rwx 
other::r‐x 
[eva@mypc ~]$ echo "hola" > MyDir/[Link] 
‐bash: MyDir/[Link]: Permiso denegado 

En  este caso “eva”  pertenece,  además  de a  su grupo privado, a los grupos “eventos” y “marketing”. En 

la  ACL  del  directorio  “MyDir”  el  primero  de  los grupos tiene permisos  de lectura y  ejecución,  así que 
puede  atravesarlo  o  entrar  y  ver  su  contenido  con  todos  los  detalles.  El  segundo,  tiene permisos  de 
lectura  y  escritura, así  que  no puede  más que obtener el  contenido,  sin los detalles. La  máscara tiene 
todos los  permisos, así  que no está limitando ningún acceso. “eva” intenta crear un archivo, pero como 
con ninguno de  los grupos  a los  que pertenece  tiene al mismo tiempo los permisos necesarios (wx)  se 
le deniega la ejecución de esta acción.  
 
Otro  punto  importante  a  considerar  es  qué  permisos  de  ACLs  se  le  asignan  por  defecto  a un 
archivo  o  directorio  cuando  es  creado.  En  principio,  cuando  se  crean,  sus  ACLs  están  vacías,  sólo   se 
asignan  los  propietarios  y permisos “ugo” como  se  explicó  anteriormente.  Sin embargo,  dentro  de un  
directorio podemos modificar  este comportamiento, especificando  qué permisos por defecto deberían 
tener  los  archivos  creados  allí.  Esto  se   realiza  mediante  los  permisos  por  defecto,  que  no  se  deben 
confundir con los del directorio. Por ejemplo: 
[eva@mypc ~]$ mkdir DirDef 
[eva@mypc ~]$ ls ‐ld DirDef/ 
drwxrwxr‐x. 2 eva eva 4096 ene 20 11:01 DirDef/ 
[eva@mypc ~]$ chmod o= DirDef/ 
[eva@mypc ~]$ setfacl ‐m g:eventos:rx DirDef 
[eva@mypc ~]$ setfacl ‐m d:g:eventos:rwx DirDef 
[eva@mypc ~]$ getfacl DirDef/ 
# file: DirDef/ 
# owner: eva 
# group: eva 
user::rwx 
group::rwx 
group:eventos:r‐x 
mask::rwx 
other::‐‐‐ 
default:user::rwx 
default:group::rwx 
default:group:eventos:rwx 
default:mask::rwx 
default:other::‐‐‐ 

“eva”  crea  un  directorio,  “DirDef”,  y  le  quita  los  permisos  por  defecto  a  “otros”,  que  se  habían 
generado por  la configuración  de ​umask​ ,  para que todo el mundo no tenga acceso. Al grupo eventos le 
 
 
Conceptos básicos de administración Linux 
 

da  permisos  de  lectura  y  ejecución.  Luego,  establece  los  permisos  por  defecto,  esto  es,  no  los  del 
directorio  en  sí,  sino  los  que  tendrán  los  archivos  que  se  creen  dentro de  él.  Finalmente  muestra  el 
contenido  de  la  ACL  de  ese  directorio.  Pueden  distinguirse  claramente  los  permisos  reales  del 
directorio, en  las primeras filas y,  al  final, los permisos  por defecto, que  van precedidos por la palabra 
default​
.  Por lo tanto, los miembros del grupo “eventos”,  no tendrán permiso para crear nada dentro de 
“DirDef”,  aunque  pueden ver su  contenido  y  entrar en él. Otra cosa ocurriría con los directorios que se 
creen dentro. Vamos a verlo:  
[eva@mypc ~]$ cd DirDef/ 
[eva@mypc DirDef]$ echo "hola" > [Link] 
[eva@mypc DirDef]$ getfacl [Link]  
# file: [Link] 
# owner: eva 
# group: eva 
user::rw‐ 
group::rwx            #effective:rw‐ 
group:eventos:rwx        #effective:rw‐ 
mask::rw‐ 
other::‐‐‐ 
 
[eva@mypc DirDef]$ mkdir OtherD 
[eva@mypc DirDef]$ getfacl OtherD/ 
# file: OtherD/ 
# owner: eva 
# group: eva 
user::rwx 
group::rwx 
group:eventos:rwx 
mask::rwx 
other::‐‐‐ 
default:user::rwx 
default:group::rwx 
default:group:eventos:rwx 
default:mask::rwx 
default:other::‐‐‐ 

Al crear el archivo “[Link]”, se le añaden en la ACL los permisos que habíamos fijado por defecto, aunque 
como  se trata  de un archivo la ejecución no se tiene en cuenta. Aquí el  sistema hace un pequeño truco, 
realmente  fija  el  permiso  de  ejecución  (​ group:eventos:rwx​ ),  pero  lo  limita  con   la  máscara 
mask::rw‐​
(​ ).  Al crear  un  directorio  (“OtherD”) también se fijan automáticamente los permisos que se 
deseaban.  Cabe  destacar  que aunque los  miembros  del  grupo “eventos” no  puedan crear  archivos  en 
“DirDef”,  sí lo pueden hacer en este nuevo directorio, pues posee todos los permisos activos para dicho 
grupo.  
 
2.5. Cuotas de disco 
 
En  un  sistema  multiusuario,  por  grande  que  sea  su  sistema  de  almacenamiento,  suele  ser 
necesario limitar  el espacio que cada  usuario o grupo  de usuarios  puede utilizar del mismo, ya que un 
uso  excesivo  de un  recurso  puede perjudicar al resto de usuarios que lo comparten. En Linux  es posible 
configurar un sistema de cuotas, que permite realizar estas labores de control.  
La  cuotas  sólo pueden fijarse  para un sistema de ficheros completo, no a partes del mismo. Por 
ello, cuando se diseñan las particiones del sistema de almacenamiento, es necesario que los directorios 
a  los  que  se  aplicarán   restricciones  de  cuotas,  queden  montados  en  un  sistema  de  archivos 
independiente.  Además,  no  suele  ser  útil  aplicar  cuotas  a  aquellos  directorios  a los que no acceden  
múltiples  usuarios  para  crear  contenidos,  como  ​/usr​ ,  sino  a  aquellos  que  son  compartidos  por  los 
mismos,  como  el  directorio  donde  se  encuentran  las  carpetas  ​ home  de  los  usuarios,  habitualmente 
 
 
Conceptos básicos de administración Linux 
 

/home​ . Esta  es  una de las razones por las que ​

/home​  suele corresponder a un sistema archivos propio. 
Para  que  al  sistema  de archivos se le  puedan aplicar  las cuotas, debe  ser  montado con  esa  opción,  lo 
que se especifica en el fichero ​ /etc/fstab​ . Por ejemplo: 
/dev/VolGroup/LogVol1 /home     ext3    defaults,usrquota  1 2 
donde,  además  de  la  indicación  de  que  el  montaje  del  volumen  lógico  indicado  se  realizará  en  el 
directorio  ​
/home​ ext3​
,  con  las  opciones  por  defecto  para  ​ ,  se  ha  indicado  que  estará disponible  para  
utilizar  cuotas  aplicadas  a  usuarios  (​ usrquota​ ).  Las  cuotas  pueden  ser  configuradas  para  usuarios 
individuales,  cualquiera que  aparezca  en el  fichero ​ /etc/passwd​ , o para cualquiera de los grupos que 
aparece en  ​/etc/group​ .  En este  último  caso, especificado  en ​ /etc/fstab con la opción g ​rpquota​ , 
el límite de almacenamiento corresponderá a la suma de todos los usuarios que pertenecen al mismo. 
Además,  a  cada  usuario  o  grupo  se  le  pueden  aplicar  dos  tipos  de  límites.  El  primero  es  al 
tamaño  total  del  almacenamiento  que  puede  utilizar  y  el  segundo  es  al  número  de  archivos  o  
directorios  que  puede  crear.  Por  ejemplo,  ésta  podría  ser  la  configuración  típica  de las cuotas  de un 
usuario: 
Disk quotas for user eva (uid 500):   
Filesystem                blocks     soft     hard    inodes   soft   hard   
/dev/VolGroup/LogVol01      8456    10000     12000      425      0      0 

En  este  caso,  “eva”  tiene  ocupados  actualmente  8456 bloques  del  sistema  de archivos. El  tamaño  de 
cada   bloque  para  el  sistema  de  cuotas  está  fijado  en  el  ​ kernel  del  sistema  y  en  la  mayoría  de  las 
distribuciones  Linux  es  de 1024  bytes (1kB).  Esta usuaria  tiene fijado  un  límite  blando  (​ soft​
) de  10000 
bloques  y  un  límite  duro  (​ hard​)  de  12000  bloques.  El  límite   duro  nunca  puede  ser sobrepasado.  Por 
ejemplo,  si  intenta  crear  un  archivo  de  un  tamaño  mayor  al  espacio  que  le  quede  disponible,  se 
escribirá sólo  la parte que quepa. Sin embargo, el límite blando puede ser sobrepasado eventualmente. 
En  ese  caso,   se  avisa  al usuario de  la situación  y se establece un tiempo  (periodo de  gracia) para  que 
solucione el problema. Si se cumple el  periodo  de gracia sin haber liberado ese espacio, se  bloquea  la 
cuenta.  En  el  ejemplo,  “eva”  posee  425 archivos o directorios, cada  uno  correspondiente a un  inodo, 
pero  no  se  ha   especificado  ningún  límite,  ni  blando  ni  duro,  sobre  el  número  de  inodos  que  puede 
tener. 
Los  pasos  y  comandos  necesarios  para  establecer  y  administrar  las  cuotas  de  disco  pueden 
consultarse  en  los   manuales  de  las  distintas  distribuciones  Linux,  por  ejemplo  el  de  RedHat15 ,  o  en 
múltiples libros de texto y manuales. 
 
2.6. Control de acceso obligatorio (MAC ‐ Mandatory Access Control) 
 
El  control  de   accesos  visto hasta ahora, basado  en la  propiedad  de  los archivos y  los  permisos 
asignados  a  los  mismos,   es  habitualmente  denominado  control  de  acceso  discrecional  (DAC  ‐ 
discretionary  access  control​ ).  En  este  tipo  de  accesos  cada  objeto  tiene  un  dueño  que  controla   los 
permisos  para  acceder  al  mismo.  Esto  presenta  algunos  problemas  de  seguridad  que  no  controla 
directamente  el   administrador.  Por  ejemplo  el  archivo  /etc/shadow  puede  ser  leído  sólo  por   el 
administrador,  pero  si  alguien   logra  ejecutar  algún programa,  mal  configurado o programado,  que  se 
ejecuta  con  privilegios  de  ​root  podría  leer  o  copiar  este  archivo  e  intentar  descifrar  los  ​
passwords 
almacenados  en  el  mismo.  Esto   ocurre  también  con  muchos  servicios  o  demonios  del  sistema  que 
suelen correr con  privilegios  y  que  pueden tener algún fallo de seguridad. Además, los usuarios son los 

15
 "Chapter 16. Disk Quotas ‐ Red Hat Customer Portal." 2014. 20 
<​
[Link]
[Link]​> 
 
 
Conceptos básicos de administración Linux 
 

propietarios  de sus archivos y pueden,  por falta  de conocimiento o de  forma premeditada, permitir el 

acceso a  otros usuarios  no  deseados  a  su información. De  esta forma la seguridad del sistema queda a 
la  “discreción”  del  uso  responsable  de  los  usuarios  y  de  un  correcto   desarrollo  de  los  procesos  que 
corren en el sistema.  
Los  sistemas  de  control  de  acceso  obligatorio  (MAC),  al  contrario  que  los  sistemas  DAC, 
proporcionan  al  administrador  control  total  sobre  lo  que  es  o  no  permitido  en  el  sistema.  Su 
funcionamiento  está   basado  en  las  políticas  que  configure  dicho  administrador,  en  las  que se  define 
qué  se  le  permite  hacer  a  cada proceso. En este caso los usuarios no pueden cambiar las  políticas,  ni 
siquiera sobre los recursos que ellos poseen, evitando un uso discrecional de la seguridad. 
El  sistema  MAC  no  sustituye  al  sistema  DAC  en  Linux,  ambos  funcionan  al mismo tiempo. De 
hecho,  primero  se comprueban  los permisos  tradicionales y si el  acceso  es permitido, el  sistema  MAC 
comprueba que existen reglas que permiten al proceso acceder realmente a los recursos o comunicarse 
con  otros  procesos.  De  este  modo,  por  ejemplo,  los  servicios  corren  en  un  “dominio”  específico  y 
aunque  tengan  privilegios  sólo  pueden  acceder  a  los  recursos  para  los  que  las  reglas  definidas 
relacionen dicho dominio con el tipo de  recursos al que pretenden acceder. En Linux la implementación 
Security  Enhancement  Linux​
más  extendida  es  SELinux16   17   (​ ),  si  bien  existen  otras  implementaciones 
como ​ AppArmor ​ 18
 o ​
TOMOYO ‐​19
AKARI​.  
La  configuración de  estos sistemas de seguridad está fuera del alcance de una asignatura básica 
de  administración  de  sistemas,  quedando  relegado  su  estudio  en   aquellas  asignaturas  de  cursos 
superiores relacionadas con la seguridad en sistemas.  
 
 
 
   

16
 "SELinux ‐ Wikipedia." 2011. <​
[Link] > 
17
 "SELinux User's and Administrator's Guide ‐ Red Hat ..." 2014. 
<​[Link]
de/​ > 
18
 "AppArmor ‐ Wikipedia, the free encyclopedia." 2011. 21 Jan. 2016 <​[Link]
> 
19
 "TOMOYO Linux ‐ Wikipedia, the free encyclopedia." 2011. 21 Jan. 2016 <​ [Link]
> 
 
 
Conceptos básicos de administración Linux 
 

 
 

3. LDAP ‐ OpenLDAP 
 
En  este  capítulo  se  presentarán  las  características  principales  de  los  servicios  de  directorio, 
centrándonos en LDAP y concretamente en la implementación más utilizada en Linux, openLDAP20.  
 
3.1. Servicios de Directorio 
Atendiendo  al  diccionario  de  la  RAE21,  una  de  las  definiciones  de  “directorio”,  la  que  nos 
interesa  en  este  contexto,  es:  “Guía  en la  que figuran las personas de un conjunto, con  indicación  de 
diversos  datos  de  ellas,   como  su  cargo,  sus  señas,  su  teléfono,  etc.”.  Las  personas  usamos 
frecuentemente  este  tipo  de  herramientas, por  ejemplo  para buscar contactos  en  el  móvil, encontrar 
empresas  que  ofrezcan  un  servicio  particular,  tanto  a  través  de  internet  como  en  las  “páginas 
amarillas”  editadas en papel,  etc.  Este concepto  de directorio  puede extenderse  en el contexto de los 
sistemas  informáticos,  entendiendo   que  no  sólo  se  puede  tratar  de  un  repositorio  en  el  que  se 
almacenan de forma conveniente los datos de personas o empresas, sino de cualquier “objeto” que sea 
de  interés,  como  impresoras,  equipos  de  sobremesa,  sistemas  de  acceso,  …  Además,  un  directorio 
debe proporcionar  los  servicios  necesarios  para permitir un  acceso  fácil y  seguro  a la  información que 
contiene. De esta forma,  un  servidor  de directorio es el encargado de proporcionar las funcionalidades 
que  necesitan  los  clientes,  a  través  de  los  estándares  adecuados,  aislando  a  los  usuarios  y  las 
aplicaciones de la infraestructura concreta en la que los datos son almacenados.  

 
En  el campo de la administración de sistemas informáticos, además de los usos comentados, los  
servicios  de  directorio  suelen  emplearse  como  una  herramienta  para  la  gestión  centralizada  de  las 
cuentas de  los usuarios, así como de los grupos correspondientes, permitiendo que los usuarios posean 
username​
un  único   ​ UID​
,  o  ​ ,  y  ​
password  para  el  acceso  a  distintos  equipos  y  servicios  dentro  de  la 
organización.   
En  ocasiones  se  piensa  en  los  servicios  de  directorio  como  bases  de  datos  comunes.  Sin 
embargo  mantienen ciertas  diferencias  con las bases de datos relacionales comúnmente utilizadas. Las 
principales son: 
● Los  objetos  almacenados  en  el  repositorio  son  generalmente  pequeños  y  la  información  está 
especificada mediante atributos. 

20
 "OpenLDAP Software 2.4 Administrator's Guide." 2007. 25 Jan. 2016 <​
[Link]
> 
21
 "Real Academia Española." 28 Jan. 2016 <​
[Link]
> 
 
 
Conceptos básicos de administración Linux 
 

● Normalmente,  para  garantizar  la  disponibilidad  y  el  balance  de  carga,  los   datos  suelen  estar 
replicados en distintos servidores. 
● Los  datos suelen  consultarse frecuentemente, pues son necesarios para diferentes operaciones, 
siendo  mucho  más  frecuentes  las  búsquedas  de  información  que  las  modificaciones  de  la 
misma.  Por  ejemplo,   no  esperamos  que  el  nombre  de  los  usuarios  o  la  descripción  de  las 
impresoras  cambie  a   menudo,  pero  sí  que  se  consulten  con  frecuencia.  Por lo tanto,  para  su 
diseño se sigue el principio WORM22  (Write Once, Read Many).  
● Los  datos  se  estructuran  en forma  jerárquica y no se atiende  de forma  estricta al  concepto de 
tabla o a los principios de control de posible duplicidad o redundancia.  
 

3.1.1. Breve historia 
Diversas  compañías   han  creado  diferentes  servicios  propietarios,  destinados  a la  gestión de  la 
información  asociada  a  una  aplicación  o sistema concretos. Sin  embargo, el  conjunto  de estándares  y 
protocolos  conocidos  como  X.50023   generalizó en gran  medida  las aplicaciones y  usos de los  sistemas 
de  directorio.  Estos  estándares  fueron  auspiciados  por  la  ISO24   (​ International  Organization  for 
Standardization​ 25
), incorporándolos  a la  estructura OSI  (​ Open Systems Interconnection​ ). Los estándares 
DAP  ‐  Directory Access Protocol​
definidos  en  X.500  incluyen  el  protocolo  de  acceso  al  directorio  (​ ),  el 
protocolo  de  sistema  de  directorio  (​DSP  ‐  Directory  System  Protocol​),  el   protocolo  de  ocultación  de 
información de directorio (​ DISP  ‐ Directory Information Shadowing  Protocol​ ),  y el  protocolo de gestión 
de enlaces operativos de directorio (​ DOP ‐ Directory Operational Bindings Management Protocol​ ). 
La  implementación  de  servicios  de  directorio  que cumplan con  todos  los  estándares definidos 
en X.500 es una tarea compleja, al estar diseñado para ofrecer sistemas generales  y altamente flexibles. 
DAP​
Además,  el  protocolo  de  acceso  al  directorio  (​ )  es  también  complejo,  limitando  el  desarrollo  de 
aplicaciones  que  hagan  uso  del  mismo  para  la   consulta  de  información.  Por  todo   ello,  no  ha  sido 
ampliamente  adoptado por la industria. Con el fin de facilitar el uso de los directorios y continuar con la 
experiencia ganada  con el desarrollo de X.500, a finales del siglo pasado se comenzó el desarrollo  de un 
nuevo  estándar  para  la  comunicación  entre  las  aplicaciones  cliente  y  los  servicios  de  directorio, 
tomando  la esencia  de ​ DAP  pero simplificándolo  o aligerándolo, dando  lugar  así a LDAP26  (​ Lightweight 
Directory  Access  Protocol​
) o ​
DAP ​ligero​. Además  el diseño LDAP se basa en la comunicación a través de 
TCP/IP (​Transmission Control  Protocol/Internet Protocol​ ) lo que lo hace más fácil de implementar en las 
redes  de  comunicación  actuales.   De  esta  forma,  se  han desarrollado  múltiples  servicios  de directorio 
basados  en  LDAP27   que  permiten  la  interoperabilidad  entre  distintos  desarrolladores.  Es  necesario 
recalcar,  que  LDAP,   como  su  nombre  indica,  no  afecta  a  la  forma  en  la  que  el  servidor  es 
implementado,   o  al  tipo  de   base  de  datos  en  la  que  se  almacenan  los  datos  o  a  la  forma  de 
comunicarse  con  ella,  sólo a cómo  los clientes acceden  al directorio. Por ello, los  distintos desarrollos 
realizan  implementaciones  diferentes,  aunque  compatibles  en su  interfaz con las  aplicaciones cliente. 
De  esta  forma,  los  estándares  incluidos  en  LDAP  definen  un  protocolo  basado  en  mensajes  para 
comunicar los clientes del directorio con el servidor del mismo.  

22
 "Write Once Read Many ‐ Wikipedia, la enciclopedia libre." 2011. <​ [Link]
> 
23
 "X.500 ‐ Wikipedia, the free encyclopedia." 2011. <​[Link]
24
 "About ISO ‐ ISO." 2012. <​[Link] > 
25
 "Modelo OSI ‐ Wikipedia, la enciclopedia libre." 2011. <​
[Link] > 
26
 "Lightweight Directory Access Protocol ‐ Wikipedia, the free ..." 2011. 
<​[Link] > 
27
 "List of LDAP software ‐ Wikipedia, the free encyclopedia." 2011. 
<​[Link] > 
 
 
Conceptos básicos de administración Linux 
 

3.2. LDAP (Lightweight Directory Access Protocol) 
Para  explorar  las  características  de  LDAP  es  conveniente  conocer  los 4 modelos en  los que  se 
basa: 
● Modelo  de  información​ .  Determina  la  estructura  de  la  información  que  es  almacenada  en  el 
directorio.  
● Modelo  de  nombres​ .  Define  cómo   se  organiza  la  información  en  el  directorio  y  cómo  es 
identificada.   
● Modelo funcional​ . Define las operaciones que pueden realizarse sobre el directorio. 
● Modelo de seguridad​ . Define cómo proteger la información  contenida en el directorio.  
A continuación se explicará cada uno de estos modelos. 
 

3.2.1. Modelo de Información 
La  unidad  básica  de  información  almacenada   en  un  directorio  se  denomina   ​entrada​ .  Cada 
entrada contiene la  información relevante para  el objeto  real al  que  representa,  ya  sea  un usuario del 
sistema,  una  organización,  una  impresora,  etc.  Cada  entrada  contiene  uno  o  más  ​
atributos​,  que son 
pares  “clave‐valor”28   que  contienen  la   información  de  dicha  entrada.  La  “clave”  del  atributo 
corresponde  al “tipo de atributo” y define qué tipo de información puede ser almacenada en el mismo. 
El  “valor”  del  atributo  contiene  la  información  en  sí  misma.  Veamos  un  ejemplo:  Supongamos  una 
entrada almacenada en algún directorio accesible a través de LDAP que representa a una impresora de 
nuestra organización. Esta entrada contendrá diferentes atributos, con su tipo y su valor:   
 

Tipo de atributo (clave)  Valor 
objectClass  device 

cn  Color3 

description  1420 Color 

serialNumber  11552‐7746‐66 

l  Despacho 33 

owner  cn=Mariano,ou=jefes,dc=miempresa,dc=com 

Todos  los  tipos  de  atributos  del  ejemplo  tienen  nombres  de  fácil  interpretación,  excepto  “cn”  que 
significa  ​
common  name  y  “l”  que  significa  ​
localityName.  En  la  mayoría de los  casos los servidores  de 
directorio son insensibles a mayúsculas y minúsculas,  si  bien se suele utilizar el convenio ​ Camel Case29 . 
Lógicamente cada entrada tendrá un nombre que la defina, pero lo veremos más adelante. 
Los  valores  de  cada  atributo  no  tienen  un  formato  libre.  Todo  lo  contrario,  cada  vez  que  se 
define  un  nuevo tipo  de atributo es necesario asociarle  una “​ sintaxis​” particular, que indica el formato 
que  debe   tener  el  valor  asociado,  como  cadenas  de  texto  con  o  sin  caracteres  especiales,  valores 
numéricos  enteros,  etc.  Los  tipos  de  atributos  usados  en  el  ejemplo  anterior  poseen  las  siguientes 
características: 

28
 "Attribute–value pair ‐ Wikipedia, the free encyclopedia." 2012. 
<​[Link] > 
29
 "CamelCase ‐ Wikipedia, la enciclopedia libre." 2011. <​
[Link]
> 
 
 
Conceptos básicos de administración Linux 
 

Tipo de atributo  Sintaxis 

Nombre  Alias  OID  Descripción 

objectClass    [Link].4.1.1466.[Link]  Object Identifier (OID) string 

cn  commonName  [Link].4.1.1466.[Link]  Directory String, UTF‐8 

description    [Link].4.1.1466.[Link]  Directory String, UTF‐8 

serialNumber    [Link].4.1.1466.[Link]  Printable String:  latin 

alphabetic characters, numeric 
characters and these punctual 
characters ? : / ' ( ) + , ‐ . = 

l  localityName  [Link].4.1.1466.[Link]  Directory String, UTF‐8 

owner    [Link].4.1.1466.[Link]  LDAP Distinguished Name 

 
OID  ‐  Object  Identifier​
Las  posibles  sintaxis  están  registradas   por  un  identificador  de  objeto  (​ )  oficial. 
Todos  los  atributos  que  pueden  utilizarse  en  un  servidor  LDAP  y  las sintaxis  correspondientes deben 
estar definidos previamente de  forma adecuada en el ​ schema del directorio. Más información sobre el 
schema  en  breve.  En  este  ejemplo  en  particular  todas  las  sintaxis  utilizadas  comienzan  por 
[Link].4.1.1466.115.121.1,  y  corresponden al  RFC (Request For  Comments) 451730 . Si bien los tipos de 
atributos  o  la  sintaxis  pueden  ser  definidas  por  cada  organización  o  desarrollador  de  software  de 
directorios,  esto  limitaría  la  interoperabilidad,  por  lo  que  se  suelen  seguir  los  estándares.  Si  un 
desarrollador  desea  obtener  un  OID  universal  nuevo,  debe  hacerlo  a  través  del  ANSI  (​ American 
National Standards Institute​ ) o de la Internet Assigned Numbers Authority31 . 
 
object classes​
Clases de objetos (​ ) 
Hemos  visto  que  cualquier  entrada  del  directorio  debe  contener  tipos  de  atributos  que 
previamente  deben  estar  definidos  en  el  ​ schema​ .  Pero,  además,  esa  entrada  no  puede  contener 
cualquier  atributo,  sino  aquellos  definidos  en  la  clase  de  objeto  a  la  que  pertenece.  En  el  ejemplo 
objectClass: device​
anterior  la  clase  aparece  en  el  primer  atributo  de  la  tabla  (​ ).  De  nuevo,  las 
clases de objetos que  están disponibles para usar en un directorio, están  definidas en el ​ schema​ .  No se  
puede, por lo tanto, crear ninguna entrada de una clase que no se encuentre definida previamente.  
Realmente,  las clases de objetos y las  entradas del directorio funcionan de forma similar a como 
son  utilizadas  las  clases  y  objetos  en  los  lenguajes  de programación orientados  a objetos, como C++, 
Java, etc.  En ese  caso  las clases  definen  los datos o atributos y los métodos que cualquier instancia de 
las mismas puede  contener. En  el caso de LDAP, las clases de objetos definen los tipos de atributos que 
contienen,  que  pueden ser  obligatorios u optativos, y cualquier entrada del directorio debe ser de una 
de esas clases, conteniendo los atributos adecuados. 
Para continuar con el ejemplo anterior, vamos a ver las características de la clase “device”: 
 
Name:device 

30
 "RFC 4517 ‐ Lightweight Directory Access Protocol (LDAP ..." 2013. <​
[Link]
> 
31
 "Internet Assigned Numbers Authority." 2005.  <​
[Link]
 
 
Conceptos básicos de administración Linux 
 
MUST:cn 
MAY: serialNumber $ seeAlso $ owner $ ou $ o $ l $ description 
 
Podemos ver  que sólo el atributo  “cn” es  obligatorio, el resto  son  opcionales, por eso algunos  de ellos 
no aparecían con valores en la entrada del ejemplo.  
Si,  al  crear  una  nueva  entrada  del  directorio,  no  se  proporcionan  valores  correctos  (que 
cumplan  la  sintaxis  correspondiente)  a  todos  los  atributos  obligatorios  definidos  en  la  clase  a la  que 
pertenece,  dicha  creación  no  será permitida.  Los atributos opcionales, como su nombre indica, sólo se 
especificarán  si  son  de  utilidad  para  el  propósito  perseguido.  El  símbolo  “​ $​
”  es  utilizado  como 
separador. 
Un  fichero  LDIF  (se  explicará  a  continuación)  utilizado  para  crear  los  atributos  y  la  clase   de 
objeto correspondientes en el ​ schema​  de un directorio, podría tener una estructura como la siguiente: 
 attributetype ( [Link].4.1.1466.[Link] NAME 'serialNumber' EQUALITY caseIgnoreMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX [Link].4.1.1466.[Link]{64} ) 
 
 attributetype ( [Link] NAME 'seeAlso' SUP distinguishedName ) 
... 
 
 objectclass ( [Link] NAME 'device' SUP top STRUCTURAL 
   MUST cn 
   MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) ) 

La  estructura  exacta  y  significado  de  cada  campo  va  más  allá  del  alcance  de  un  curso  básico  de 
administración  de  sistemas.  Aun  así,  se  intuye  que  se  definen  los  atributos  necesarios,  sus  OIDs y  se 
especifica cómo deben realizarse las comparaciones para las búsquedas. Además, se especifica la nueva 
clase de objeto. 
Como  también  ocurre en los lenguajes orientados a objetos, es posible que una clase de objetos 
sea una  extensión de una clase padre, permitiendo a la clase hija heredar todos los atributos de la clase 
superior.  En el ejemplo anterior, el padre es la clase “top”, la primera que se define.  
En  el siguiente ejemplo  se  esquematiza la  parte  del  fichero LDIF que sirve  para introducir en el 
residentialPerson​
schema la clase  de objeto “​ ”, su  padre  o SUPerior, “​person​ ”, y, a su vez, el padre 
(del que todas las clases dependen), “​ top​
”: 
objectclass ( [Link] NAME 'top' ABSTRACT 
  MUST objectClass ) 
 
 objectclass ( [Link] NAME 'person' SUP top STRUCTURAL 
  MUST ( sn $ cn ) 
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) 
 
 objectclass ( [Link] NAME 'residentialPerson' SUP person STRUCTURAL 
  MUST l 
  MAY ( businessCategory $ x121Address $ registeredAddress $ 
   destinationIndicator $ preferredDeliveryMethod $ telexNumber $ 
   teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ 
   facsimileTelephoneNumber $ street $ 
   postOfficeBox $ postalCode $ postalAddress $ 
   physicalDeliveryOfficeName $ st $ l ) ) 

residentialPerson​
Así,  cualquier  entrada  de  la  clase  “​ ”  debe  tener  definidos  los  valores  para  los 
atributos:  ​
objectClass, sn, cn   y l​
​ . ​El  primero porque la  clase  “​residentialPerson​ ” lo  hereda 
de  “​ top​ person​
”,  los  dos  siguientes  porque  los  hereda  de  “​ ”  y  el  último  porque  lo  agrega  la propia 
clase “​residentialPerson​ ”. Además puede dar valores a cualquiera del resto de atributos opcionales.  
 
 
Conceptos básicos de administración Linux 
 

También  es  muy  importante  saber  que  podemos  decidir  que  una  sola  entrada  pertenezca  a 
varias clases de objeto. Si  fuese de esa forma, se deben especificar  los atributos de todas  las clases a las 
que pertenezca. 
En  el ejemplo anterior también aparecen  los términos “abstracto” y “estructural”, relacionados 
con los ​
tipos de clases objetos​, que pueden ser: 
● STRUCTURAL​
:  La  mayor  parte  de  las  clases  de  objetos  son   de  este  tipo.  Las  entradas  del 
directorio  deben  pertenecer  al  menos  a  una  clase  de  este  tipo.  No  puede  pertenecer  a  dos 
clases  “estructurales”  a  no  ser   que  estén  dentro  de  la  misma  jerarquía,  esto  es,  que  una  sea 
hija, nieta, etc. de la otra. 
● ABSTRACT​ :  No  existen  entradas  que  pertenezcan  a  este  tipo   de  clases.  Se  usan  como  clases 
padre para,  a partir de ellas, definir otras nuevas. El caso más representativo es la clase “top”. 
● AUXILIARY​ :   Pueden  ser  clases  complementarias  de  una  entrada,  pero  nunca  la  única.  Si  una 
entrada pertenece  a una clase “estructural”, puede pertenecer a más clases, sean “auxiliares” o 
“esctructurales” (en este último caso teniendo en cuenta lo explicado en el primer caso). 
 
Directory schema​
Esquema del directorio (​ ) 
El  ​
schema  de  un  directorio  LDAP  consiste  en  un  conjunto  de  definiciones  y  reglas  que 
determinan  el  tipo  de  información  que  puede ser  almacenada  en  el  directorio. Los  tipos de atributos 
disponibles,  así  como  las  clases  de  objetos  a  las  que  pueden  pertenecer  las  entradas  del  directorio 
están recogidas en el ​schema​ . Cada vez que se intenta introducir una nueva entrada en el directorio,  las 
reglas  del  ​
schema  son  consultadas  para  determinar  si  dicha  operación  es  permitida.  Cada  nueva 
entrada debe pertenecer al menos a una clase  estructural definida en el esquema y, además, todos los 
atributos  obligatorios  deben  contener  valores  adecuados.  Por  supuesto,  una  entrada  no  puede 
contener atributos que no hayan sido definidos para las clases de objeto a las que pertenezca.  
Cualquiera puede  extender el  ​ schema para  incorporar aquellas  clases de objetos, y sus tipos de 
atributos,  que  son  necesarios  para  gestionar  la  información  de  la  organización.  Sin embargo,  existen 
muchos atributos  y  clases que son estándares,  por lo que debe  investigarse si entre  los disponibles  se 
encuentran algunos  que puedan  ser  de  utilidad. Esto mejora, asimismo,  la interoperabilidad con otros 
sistemas.  
Por  ejemplo,  si  deseamos  utilizar  LDAP  para  centralizar  la  gestión  de  los  usuarios  y  la 
autenticación de los  mismos,  independientemente del dispositivo al que accedan, podemos utilizar  las 
siguientes  clases  de  objetos,  ya  que  incluyen  los  campos  que  habitualmente  se  encuentran  en  los 
/etc/passwd​
archivos ​ /etc/group​
 y ​  en los sistemas Linux de forma local: 
objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top STRUCTURAL 
MUST userid 
MAY ( description $ seeAlso $ localityName $ 
organizationName $ organizationalUnitName $ host ) 
) 
objectclass ( [Link].[Link] NAME 'posixAccount' SUP top AUXILIARY 
DESC 'Abstraction of an account with POSIX attributes' 
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) 
MAY ( userPassword $ loginShell $ gecos $ description ) ) 
 
objectclass ( [Link].[Link] NAME 'posixGroup' SUP top STRUCTURAL 
DESC 'Abstraction of a group of accounts' 
MUST ( cn $ gidNumber ) 
MAY ( userPassword $ memberUid $ description ) ) 
 
 
Conceptos básicos de administración Linux 
 

3.2.2. Modelo de nombres 
El  modelo  de  nombres  de  LDAP  especifica  el  modo  en el que  se organizan  las entradas  en  un 
directorio y  cómo cada una  de esas entradas debe ser identificada unívocamente. La recomendación es 
que  las  entradas  sean  almacenadas,  de  manera  lógica,  en  forma  de  árbol,  siguiendo  un  esquema 
jerárquico.  Como  vemos,  esta  jerarquía  está  en  todas  las   facetas  de  LDAP,  como en  las entradas,  las 
clases  de  objetos  y  atributos,  etc.  Este  árbol  de  entradas  se  denomina  habitualmente  árbol  de 
información del directorio (​ DIT ‐ Directory Information Tree​ ).  

 
Vemos  que  se  trata de  un árbol invertido, similar al esquema utilizado para los directorios de un 
sistema de archivos.  
En  el caso de  LDAP  la raíz del árbol se denomina “base” o “sufijo” y corresponde habitualmente 
con el  nombre de  la  organización para  la que  el  directorio ha sido diseñado. Se pueden emplear varias 
formas para definir  esta raíz. Nosotros  usaremos  una basada en  el RFC 224732 , del que parten  las más 
empleadas  en  sistemas  UNIX  y  Windows  (Active  Directory),  y  compatible  con  los  nombres  utilizados 
habitualmente  en  DNS33   y  a   los  que  estamos  acostumbrados  por  el  uso  de  internet.  Para  ello  se 
empleará las clases de objetos: 
 attributetype ( 0.9.2342.19200300.100.1.25  NAME ( 'dc' 'domainComponent' ) 
   EQUALITY caseIgnoreIA5Match 
   SUBSTR caseIgnoreIA5SubstringsMatch 
   SYNTAX [Link].4.1.1466.[Link] SINGLE‐VALUE ) 
 
 attributetype ( [Link] NAME ( 'o' 'organizationName' ) SUP name ) 
 
 objectclass ( [Link] NAME 'organization' SUP top STRUCTURAL 
  MUST o 
  MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ 
   x121Address $ registeredAddress $ destinationIndicator $ 
   preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ 
   telephoneNumber $ internationaliSDNNumber $ 
   facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ 
   postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) 
 
 objectclass ( [Link].4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY  
  MUST dc ) 

Cada clase de objeto posee sólo un atributo obligatorio, cuya definición también se ha incluido.   
Por, ejemplo para la organización “[Link]” la base sería: 

32
 Grimstad, A. "[Link] ‐ RFC Editor." 2013. <​
[Link]
> 
33
 "Domain Name System ‐ Wikipedia, la enciclopedia libre." 2011. <​[Link]
> 
 
 
Conceptos básicos de administración Linux 
 

   dn: dc=mycompany,dc=com 
   objectClass: organization 
   objectClass: dcObject 
   dc: mycompany 
   o: My Company S.L. 

Se  ha  especificado  en  el  formato  LDIF,  que  se  describirá  a  continuación.  Vemos  que  la  entrada 
pertenece  a  dos  clases,  lo  cual,  como  habíamos  comentado,  es  posible,  ya  que  una  entrada  puede 
pertenecer  a  múltiples  clases.  De  hecho,  no  puede  pertenecer  sólo a la clase  “​ dcObject​ ” pues es de 
tipo  auxiliar,  no  estructural.  Al  final,  se  da  valor  a  cada  uno   de  los  atributos  obligatorios   de  dichas 
clases.  
En  ocasiones  se  usa esta otra clase,  que sí es  estructural  y  permite  crear una  entrada  sólo con 
ella: 
 objectclass ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL 
MUST domainComponent 
MAY ( associatedName $ organizationName $ description $ 
businessCategory $ seeAlso $ searchGuide $ userPassword $ 
localityName $ stateOrProvinceName $ streetAddress $ 
physicalDeliveryOfficeName $ postalAddress $ postalCode $ 
postOfficeBox $ streetAddress $ 
facsimileTelephoneNumber $ internationalISDNNumber $ 
telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ 
preferredDeliveryMethod $ destinationIndicator $ 
registeredAddress $ x121Address ) 
) 

Quedando la entrada: 
   dn: dc=mycompany,dc=com 
   objectClass: domain 
   dc: mycompany 

 
A partir de la base se puede seguir creando el árbol, por ejemplo: 

 
 
Distinguished name​
Nombre distintivo (​ ) 
En  el  ejemplo  anterior  se  muestran  diferentes  entradas  del  árbol  del  directorio.  Cada una  de 
ellas  está  identificada por  el valor de uno  de sus atributos obligatorios. Podría ser cualquiera de  ellos, 
pero  generalmente  se  usa  el  más   característico.  Esa  identificación  se  denomina  nombre  distintivo  
relativo (RDN ‐ ​ Relative Distinguished Name​ ) y no tiene porqué ser único en el directorio, pero sí dentro 
de  la rama  en la que se encuentra. Por ejemplo, dentro “ou=jefes” (la unidad organizativa en la que se 
incluye  a los jefes, como si fuese una carpeta donde agrupar las entradas con algún aspecto en común), 
no  podrían  existir  dos  entradas  con  el  mismo  RDN.  Si  se  escoge  un  atributo  que  se  repite  mucho, 
pueden  usarse  dos  atributos,  separados  por un signo “+”,  para identificar cada  entrada  (por ejemplo, 
 
 
Conceptos básicos de administración Linux 
 

uid=alberto+uidNumber=503, aunque el ​ login name  ​
de un usuario no debería  repetirse). Sin embargo, 
una  entrada   no  queda  totalmente  identificada  con  su  RDN, pero,  como éste  es  único en  la rama  del 
árbol  en  la  que  se  encuentra,  quedaría  unívocamente  identificada  con  su  RDN  más  todos  los  RDNs  
hasta llegar a la raíz del árbol.  Por ejemplo: dn:u   id=juan,uo=jefes,dc=mycompany,dc=com​ . A esta 
identificación única se le  denomina nombre distintivo (DN) y es la forma que se usa habitualmente para 
referirse a las distintas entradas del directorio.  
 
Formato LDIF 
LDIF34   (LDAP  Data  Interchange   Format)  es  un  formato  de  texto  estándar  para  representar  el 
contenido de  directorios o para actualizar los mismos.  Es decir, existen herramientas que  nos permiten 
leer  el contenido de un directorio o  parte del mismo y generar un archivo de texto en formato LDIF, de 
forma  que  sea  fácilmente  leído  por  un   humano  o  importado  por  otro directorio. Además,  es  posible 
escribir ficheros LDIF y usar utilidades que se comuniquen con un directorio LDAP para que éste genere 
las  entradas  correspondientes,  transformando  el  texto  del  archivo  en  el  formato  que  se  use  en  el 
directorio, que puede ser diferente para cada ​ software ​ de directorio o dependiente de la base de datos 
que se utilice. 
El formato de cada entrada en un archivo LDIF es de la forma:  
#comment 
dn: <distinguished name> 
objectClass: <object class> 
objectClass: <object class> 
... 
... 
<attribute type>: <attribute value> 
<attribute type>: <attribute value> 
... 
 
Por  ejemplo,  para  crear  la   rama  izquierda  del  árbol del  ejemplo  anterior se podría  hacer mediante el 
fichero LDIF: 
dn: dc=mycompany,dc=com 
objectClass: domain 
dc: mycompany 
 
dn: ou=jefes,dc=mycompany,dc=com 
objectClass: organizationalUnit 
ou: jefes 
 
dn: uid=juan,ou=jefes,dc=mycompany,dc=com 
objectClass: account 
objectClass: posixAccount 
uid: juan 
cn: juan 
loginShell: /bin/bash 
uidNumber: 503 
gidNumber: 503 
homeDirectory: /home/juan 

Se  trata  de  un  supuesto  sencillo,  en  el  que  se  han  incluido  campos  mínimos  a  modo  de ejemplo. Se 
debe  notar  que  entre  dos  entradas  siempre  debe  existir  una  línea  en  blanco.  Además  el  orden  es 
importante,  ya  que  el  archivo  se  leerá  de  forma  secuencial,  así  que  si  no  se  ha  creado  la raíz, no se 
puede  crear  la  unidad  organizativa  y  hasta  que  ésta  no  esté  creada  no  se  puede  crear la  entrada  de 
“juan”. Lógicamente si sólo deseamos crear esta última entrada, pues el  árbol ya estaba creado hasta la 
34
 Good, G. "RFC 2849 ‐ Internet Engineering Task Force." 2000. <​
[Link]
> 
 
 
Conceptos básicos de administración Linux 
 

unidad organizativa,  no habría  que  volver  a intentar crear esas entradas, de hecho provocaría un error, 

tan  solo  la nueva.  Podemos destacar  asimismo, que la  última entrada pertenece a dos clases, ya que, 
aunque los atributos suministrados están todos definidos en la clase “​ posixAccount​ ”, ​
ésta es auxiliar, 
por lo que es necesario que pertenezca a una clase estructural, en este caso “​ account​”. 

3.2.3. Modelo Funcional 
El  modelo  funcional  de  LDAP  describe  las  operaciones  de  acceso  y  modificación  que  pueden 
realizarse  a  través  de  dicho  protocolo.  Estas  operaciones  las  podemos  agrupar  en  tres  categorías: 
interrogación (​ query​ update​
), actualización (​ authentication​
) y autenticación (​ ).  
Las  operaciones  de  ​interrogación  son  utilizadas  para  obtener  información  del  directorio.  Para 
ello,  es  necesario  realizar  una  consulta  de búsqueda  al servidor LDAP. En  dicha  consulta  es  necesario 
especificar el  punto  de inicio  de la misma dentro  del  DIT (base), la profundidad (​ scope​) de la búsqueda 
y el filtro, basado en los valores de los atributos que debe poseer una entrada.  
En  el  filtro  podemos  utilizar  operaciones  de  comparación  y  lógicas  similares  a  las  usadas 
normalmente en los lenguajes de programación, como =, >=, <=, =*, ~=, &, |, !. 
scope​
En  el  ámbito  o  profundidad  de  la  búsqueda  (​ )  podemos  utilizar  las  siguientes  cuatro 
opciones: 
● Base​
:  Busca  coincidencia  sólo  en  la  entrada  especificada  como  “base”,  es  decir  el  nodo  o 
entrada del DIT en el que se comienza la búsqueda.  
● Un nivel (“​one” level​): Busca un  nivel  por debajo de la entrada especificada como base, es decir 
en todas las entradas que tienen como padre a la base. 
● sub​
Sub‐árbol  (“​ ”‐tree):  Busca  en  toda  la  porción  del  DIT  cuya  raíz  es  la  base  especificada, 
incluyendo la propia base. 
● children​
Hijo (​ ): Igual que el anterior, pero excluye la raíz del sub‐árbol. 
 
Para ejemplificar las búsquedas en LDAP, supongamos el siguiente árbol: 

 
 
Si  realizamos  búsquedas  con  “​ scope​
”  igual  a  “base”  sólo  lograremos  coincidencias  si  la  base 
especificada  contienen  el  término  buscado  en  el  filtro.  Las respuestas del comando ​ ldapsearch  han 
sido  simplificadas,  borrando  toda  la información  que  no sea el  DN de cada entrada o los  mensajes  de 
error o resumen de resultados: 
 
  
 
 
Conceptos básicos de administración Linux 
 

$ ldapsearch ‐h localhost ‐x ‐s base ‐b "dc=mycompany,dc=com" "uid=ju*" 
 
result: 0 Success 
 
$ ldapsearch ‐h localhost ‐x ‐s base ‐b "ou=Level1,dc=mycompany,dc=com" "uid=ju*" 
 
result: 0 Success 
 
$ ldapsearch ‐h localhost ‐x ‐s base ‐b "uid=justo,ou=Level1,dc=mycompany,dc=com" "uid=ju*" 
dn: uid=justo,ou=level1,dc=mycompany,dc=com 
uid: justo 
# numEntries: 1 
result: 0 Success 

scope​
En  el  comando  usado,  “‐s  ”  indica  el  “​ ”,  “‐b”  la  base  a  partir  de  la  que  buscamos  y  el  último 
parámetro,  entre  comillas,  indica  el  filtro  de  búsqueda,  en  este  caso  aquellas  entradas  cuyo  “uid” 
comience por  “ju”. Como habíamos  comentado, sólo cuando la propia base incluye el atributo buscado 
obtenemos un resultado positivo. 
 
one​
Si  usamos  el  “scope”  igual  a  “un  nivel”  (​ ),  devolverá  aquellas  entradas  que  cumplan  el 
criterio de búsqueda y cuyo padre sea la base especificada. Por ejemplo: 
$ ldapsearch ‐h localhost ‐x ‐s one ‐b "ou=Level1,dc=mycompany,dc=com" "uid=ju*" 
dn: uid=justo,ou=level1,dc=mycompany,dc=com 
# numEntries: 1 
result: 0 Success 
 
$ ldapsearch ‐h localhost ‐x ‐s one ‐b "uid=justo,ou=Level1,dc=mycompany,dc=com" "uid=ju*" 
 
result: 0 Success 

Vemos   que  en  segundo  caso  no  puede  devolver  nada,  ya  no  cuelga  ninguna  entrada  de  la  base 
especificada.  En  el  primer  caso,  dentro  de  la OU “level1” sí existe una  entrada  que  cumple  el criterio 
fijado en el filtro. 
scopes​
En  los casos de  “​ sub‐tree​
” igual a “​ children​
” o “​ ” los resultados son similares, en el último 
caso excluyendo la propia base de la búsqueda. Por ejemplo: 
$ ldapsearch ‐h localhost ‐x ‐s sub ‐b "dc=mycompany,dc=com" "uid=ju*" 
dn: uid=justo,ou=level1,dc=mycompany,dc=com 
dn: uid=juanito,ou=level2,ou=level1,dc=mycompany,dc=com 
dn: uid=juanele,ou=level2,ou=level1,dc=mycompany,dc=com 
dn: uid=justino,ou=level1B,dc=mycompany,dc=com 
# numEntries: 4 
 
$ ldapsearch ‐h localhost ‐x ‐s sub ‐b "ou=Level1,dc=mycompany,dc=com" "uid=ju*" 
dn: uid=justo,ou=level1,dc=mycompany,dc=com 
dn: uid=juanito,ou=level2,ou=level1,dc=mycompany,dc=com 
dn: uid=juanele,ou=level2,ou=level1,dc=mycompany,dc=com 
# numEntries: 3 
 
$ ldapsearch ‐h localhost ‐x ‐s sub ‐b "ou=level1B,dc=mycompany,dc=com" "uid=ju*" 
dn: uid=justino,ou=level1B,dc=mycompany,dc=com 
# numEntries: 1 
 
 
Conceptos básicos de administración Linux 
 

En  estos  tres casos vemos que  devuelve  las entradas  que cumplen  lo  especificado  en el  filtro y  que se 
encuentran por  debajo de  la base, independientemente  de si son hijas directas o están en niveles más 
alejados.  
  Las  operaciones  de  ​
actualización  comprenden  aquellas  por  las  que  se  añaden,  modifican, 
borran o  renombran entradas en  el directorio o  algunos de los  atributos de una entrada en particular. 
Por ejemplo, podemos añadir una nueva entrada al árbol anterior y comprobar que existe: 
$ cat [Link]  
dn: uid=julia,ou=level1B,dc=mycompany,dc=com 
objectClass: posixAccount 
objectClass: account 
cn: julia 
uid: julia 
loginShell: /bin/bash 
uidNumber: 2014 
gidNumber: 2014 
homeDirectory: unused 
 
$ ldapadd ‐xD "cn=admin,dc=mycompany,dc=com" ‐W ‐f [Link]  
Enter LDAP Password:  
adding new entry "uid=julia,ou=level1B,dc=mycompany,dc=com" 
 
$ ldapsearch ‐h localhost ‐x ‐s sub ‐b "ou=level1B,dc=mycompany,dc=com" "uid=jul*" 
# julia, level1B, [Link] 
dn: uid=julia,ou=level1B,dc=mycompany,dc=com 
objectClass: posixAccount 
objectClass: account 
cn: julia 
uid: julia 
loginShell: /bin/bash 
uidNumber: 2014 
gidNumber: 2014 
homeDirectory: unused 
# search result 
search: 2 
result: 0 Success 
# numResponses: 2 
# numEntries: 1 

En  el  segundo  comando  añadimos  el  contenido  del archivo LDIF ([Link])  al directorio usando  las 
credenciales del administrador del mismo, en este caso “admin”.  
En  el siguiente ejemplo, se modifica el atributo “gidNumber” de la entrada creada en el ejemplo 
anterior: 
$ cat pru_modif.ldif  
dn: uid=julia,ou=level1B,dc=mycompany,dc=com 
changetype: modify 
replace: gidNumber 
gidNumber: 2045 
 
$ ldapmodify ‐xD "cn=admin,dc=mycompany,dc=com" ‐W ‐f pru_modif.ldif  
Enter LDAP Password:  
modifying entry "uid=julia,ou=level1B,dc=mycompany,dc=com" 
 
 
 
Conceptos básicos de administración Linux 
 

$ ldapsearch ‐h localhost ‐x ‐s sub ‐b "ou=level1B,dc=mycompany,dc=com" "uid=jul*" 
… 
dn: uid=julia,ou=level1B,dc=mycompany,dc=com 
objectClass: posixAccount 
objectClass: account 
cn: justino 
uid: julia 
loginShell: /bin/bash 
uidNumber: 2014 
homeDirectory: unused 
gidNumber: 2045 
... 

O podemos borrar la entrada: 
$ ldapdelete ‐xD "cn=admin,dc=mycompany,dc=com" ‐W "uid=julia,ou=level1B,dc=mycompany,dc=com"  
Enter LDAP Password:  
 
$ ldapsearch ‐h localhost ‐x ‐s sub ‐b "ou=level1B,dc=mycompany,dc=com" "uid=jul*" 
 
result: 0 Success  

con lo que no obtenemos ningún resultado en la búsqueda. 
 
Las operaciones  de ​ autenticación son las utilizadas para conectar el cliente con el servidor LDAP 
y  finalizar  la  sesión  correspondiente.  La  operación  ​
bind  (enlace)  inicia  la  sesión  entre  el  cliente  y  el 
servidor.  Una  vez  iniciada  dicha  sesión  se  realizan  las  operaciones  de  consulta  o  actualización. 
Finalmente,  la  operación  ​ unbind  (desconexión)  termina  la sesión y desconecta al  cliente  del  servidor. 
Estas operaciones se esquematizan en la siguiente figura. 

 
 
Los  comando  vistos anteriormente, como ​ ldapsearch, ldapadd, ldapdelete​ , etc.  realizan 
todos  los  pasos  vistos  anteriormente. Sin embargo,  no  en todos ellos hemos  especificado  la identidad 
del  usuario  que  realiza  la  acción  ni  se  ha  solicitado un  ​
password. Esto  se debe  a  que la  autenticación 
puede ser de varios  tipos:  
● Anónimo  o sin  autenticación. En este  caso no se especifica el DN  de ningún usuario ni se solicita 
password​
un ​ .  Es  una forma muy común para consultas, que necesitan un acceso de lectura a las 
entradas  del  directorio,  como las  usadas por  los clientes de correo electrónico en  la búsqueda 
 
 
Conceptos básicos de administración Linux 
 

de  las  direcciones  de  usuarios.  Las  búsquedas  de  los  ejemplos  anteriores  se  han  realizado de 
forma anónima, ya que los datos que requeríamos  lo permitía.  
● Autenticación  simple.  En  este  caso  el  ​ login  del  usuario,  en  formato  DN,  y  el  correspondiente 
password​ ,  es  enviado  como  texto  simple  al  servidor  LDAP.  El  servidor  genera  el  ​ hash 
correspondiente y lo compara  con el  almacenado en  su base  de datos. Si coincide, el cliente es  
autenticado  correctamente. El  gran  problema  es  que,  como se comentó, el ​ password ​ viaja por 
la  red  en texto simple,  sin cifrar, con  lo que puede ser interceptado por terceros. De esta forma 
es  como  se  han  realizado  los  ejemplos  anteriores  de  actualización  de  LDAP,  en  el  que  se 
proporcionaba un usuario con privilegios para  la  modificación del directorio y  se preguntaba el 
password. 
● Autenticación  mediante  TLS.  En  este caso, para evitar enviar de forma insegura el ​ password​, los 
datos  se  empaquetan  mediante una capa de transporte segura. LDAP puede negociar y cifrar la 
capa  de transporte antes de realizar la  operación de ​ bind​ .  De esta forma, tanto la identidad del 
usuario  y su  clave como el resto  de las peticiones estarían cifradas, añadiendo mayor seguridad 
a  la  comunicación.  Aunque  LDAP  soporta  SSL,  este  protocolo  ha  sido  relegado  por  TLS35  
Transport Layer  Security​
(​ ) que  trabaja de forma predeterminada sobre el puerto TCP36  de LDAP, 
el 389. De esta forma permite comunicaciones  cifradas y sin cifrar sobre el mismo puerto, lo que 
facilita la gestión de los puertos habilitados. 
● Autenticación  mediante  SASL37   (​ Simple  Authentication  and  Security  Layer​ ).  SASL  puede 
utilizarse  para  añadir  mecanismos  de  autenticación  adicionales  a  los  protocolos  orientados a 
conexión,  como  LDAP.  Permite  al  cliente  y   servidor  negociar  un  mecanismo  de  autenticación 
antes  de  la  transmisión  de  cualquier  credencial  del  usuario.  Además,  ambas  partes  deben 
negociar  una  capa  de  transporte  segura,  mediante  SSL  o TLS, que  servirá  para cifrar los  datos 
enviados.  El  RFC  222238   define  varios  esquemas  de  autenticación  posibles  para  SASL,  como 
Kerberos39 , GSSAPI40 , SKEY41  o EXTERNAL. 
   

3.2.4. Modelo de Seguridad 
El  modelo  de seguridad  define la protección de  la información  contenida en el directorio LDAP, 
previniendo  el acceso a  usuarios no autorizados. Dicho  modelo se basa en  la identidad del cliente que 
intenta acceder, a través de su DN, y establece los permisos para las entradas del directorio. En general 
access control  lists​
estos  permisos  se  establecen  a  través  de  ACLs  (​ )  que  son  altamente  configurables, 
permitiendo  incluso  un  tipo  de  acceso  (gestión,  escritura,  lectura,  búsqueda,  comparación, 
autenticación,  etc.)   determinado  a  uno  o  varios  usuarios  y  a  uno  o  varias  entradas,  incluso  a  uno  o 
varios atributos individuales  de las  mismas. Por ejemplo,  podríamos permitir que sólo los usuarios que 
estuviesen  dentro de una  “ou”  pudiesen  cambiar su  propio  atributo  “cn”, que  pudiesen leer el resto y 
que el  resto de  usuarios no pudiese leer nada. Por lo tanto, se trata de una herramienta compleja pero 
bastante potente. 

35
 "SSL ‐ Wikipedia." 2011. 4 Feb. 2016 <​[Link] > 
36
 "Anexo:Números de puerto ‐ Wikipedia, la enciclopedia libre." 2011. 4 Feb. 2016 
<​[Link] > 
37
 "SASL ‐ Wikipedia, la enciclopedia libre." 2011. 4 Feb. 2016 <​
[Link] > 
38
 Myers, JG. "RFC 2222 ‐ Simple Authentication and Security Layer (SASL)." 1997. <​ [Link]
> 
39
 "Kerberos ‐ Wikipedia, la enciclopedia libre." 2011. 4 Feb. 2016 <​
[Link] > 
40
 "GSSAPI ‐ Wikipedia, la enciclopedia libre." 2011. 4 Feb. 2016 <​
[Link] > 
41
 "S/KEY ‐ Wikipedia, the free encyclopedia." 2011. 4 Feb. 2016 <​ [Link] > 
 
 
Conceptos básicos de administración Linux 
 

3.2.5. Delegación y replicación 
LDAP está  diseñado para permitir la ​ delegación de una o varias partes del árbol de información, 
manteniendo  la consistencia  del  directorio  como si se tratase de  un solo DIT.  Así una compañía puede 
referral​
crear  una  delegación   (​ )  de  responsabilidad  sobre  una  parte  del  DIT  a  un  departamento  de  la 
organización. En la siguiente figura se esquematiza un ejemplo de delegación: 

 
Podemos  observar  que  una  rama  del  árbol  no  reside  en  el  servidor  principal  (“server1”)  sino  en 
“server2”,  por  lo  que  la  gestión  del  departamento  comercial  podría  estar  delegada  a  los 
administradores  del  mismo.  Cuando un cliente pregunta al  “servidor1” por  una entrada que reside  en 
el  “servidor2”  es  redirigido  al  mismo.  Esta  redirección  puede  ser  de  dos  formas,  dependiendo  de  la 
implementación  y/o  configuración  del  servidor  LDAP.  Podría  devolver  la  información  del  segundo 
servidor  al  cliente  y  éste  preguntar  directamente  a  “server2”,   de  la  otra  forma,  el  propio  “server1” 
realizaría  la  consulta  a  “server2”  y  devolvería  la  respuesta  de  éste  al  cliente  que  ha  solicitado  la 
información, facilitando la labor al mismo. 
Además  de  una  delegación  en  la  administración de  una parte del directorio, agilizando  ciertas  
tareas  de  gestión  del   mismo,  la  implementación  de  ​referrals  tiene  otras  ventajas.  El  rendimiento  de 
acceso  al  directorio  mejora  al  repartirse  las  consultas  entre  dos  servidores  ya  que  los  clientes  del 
departamento  descentralizado   no  tendrían  que  recurrir  al  servidor  central  excepto  para  consultas 
sobre entradas que no pertenezcan a su departamento. Si dicho departamento se encuentra localizado 
en  una  ubicación  diferente,  unida  con  la  central  por  una  red  de  comunicaciones  de  área  extensa,  
también se evitan consultas remotas cuando se requiere la información del propio departamento. 
La  ​
replicación  en  LDAP  permite  tener  una  o  más  copias  de  un  directorio  en  diferentes 
servidores  creando una estructura  con tolerancia  a fallos. Por un lado, al tener una copia del directorio 
se  previene  la  pérdida  de  información  y  la  imposibilidad  de  trabajar  con  el  directorio  si  uno  de  los 
servidores  falla.  Por  otro,  las  consultas  al  directorio  pueden  realizarse  a  los  diferentes  servidores, 
posibilitando  el  balanceo  de  carga  entre  los  mismos  y  acelerando  la  respuesta  global  a  los  clientes. 
Existen dos posibles configuraciones básicas para la replicación: 
 
 
Conceptos básicos de administración Linux 
 
● Maestro‐esclavo  (​ master‐slave​ ).  En  este  caso  la  información  del  DIT  es  sólo  modificada  en  el 
servidor  maestro  y  los  esclavos  mantienen  copias  de  solo‐lectura,  que se  actualizan de  forma 
periódica o pasado un intervalo de tiempo desde la última modificación. Si bien sólo el maestro 
es  útil  para  las  modificaciones  de  la  información,  las  consultas  pueden  ser  realizadas  en 
cualquiera  de ellos, posibilitando el balanceo de carga. Si muchos clientes necesitan actualizar la 
información  se  puede  producir  un  cuello  de  botella.  Si  el  maestro  falla,  el  servicio  no  se 
interrumpe  y  la información  puede recuperarse de uno de los esclavos, pero sí se interrumpe la 
posibilidad de actualización del directorio.  
● Multi‐maestro (​ multi‐master​ ). En este caso, la información puede ser consultada y/o modificada 
en cualquier servidor, pues todos actúan como maestros.  
 
3.3. OpenLDAP 
El  proyecto OpenLDAP42   es  una implementación de  LDAP  que se  originó a partir de una versión 
anterior del directorio desarrollada por la  Universidad de  Michigan43 . Se  trata de un desarrollo basado 
en  código  abierto,  por  lo  que  está  disponible  para  múltiples  plataformas.  Además,  posee  un  amplia 
documentación  sobre  su  gestión44 .  Todo   ello  hace  que  sea  ampliamente  utilizada,  sobre   todo  en  
servidores Linux.  
Al cumplir  con los  protocolos LDAP, todos los  conceptos  expuestos  en  los apartados anteriores 
son  aplicables  a  OpenLDAP,  por  lo  que  en  esta  sección  nos  limitaremos  a  resumir  aquellos  aspectos 
característicos de la configuración de esta implementación.  
 

3.3.1. Configuración del servidor 
A partir de OpenLDAP 2.3 la configuración se puede realizar de dos formas: 
● Mediante  un  fichero  de  configuración  en  texto  simple,  habitualmente  localizado  en 
/etc/openldap/[Link]  o  / ​usr/local/etc/openldap/[Link]​ .  Éste  es  el  método 
tradicional,  que  se  mantiene  por  compatibilidad  pero  que  desaparecerá  en  las  próximas 
versiones. 
● Utilizando  la  configuración  dinámica  en  tiempo  de  ejecución,  “slapd‐config”45 .  Este  tipo  de 
slapd  ‐  Standalone  LDAP  Daemon​
configuración  puede  realizarse  sin  reiniciar  el  servicio  (​ ) 
utilizando  comandos  estándar  de  LDAP.  En  este  caso  se  almacena  la  información  de 
configuración  en  archivos  LDIF  como  paso  previo  a  la  creación  de  un  DIT  para  la  propia 
configuración.  
 
Como  esta  última  versión  es  la  aconsejada  actualmente  y  la  que  continuará  en  las  próximas 
versiones es la  que describiremos. En ​ slapd‐config la configuración del servidor OpenLDAP se almacena 
de  la misma forma que el resto de la información, en un DIT. Al arrancar el servicio,  éste lee los ficheros 
LDIF  contenidos  en  un  directorio  particular,  habitualmente  / ​etc/openldap/slapd.d/​ ,  y  crea  el 
directorio correspondiente. Este DIT tiene una forma similar al siguiente ejemplo: 
 

42
 "OpenLDAP, Main Page."  <​[Link]
43
 "SLAPD and SLURPD Administrators Guide." 2005.  <​
[Link]
> 
44
 "OpenLDAP Software 2.4 Administrator's Guide." 2007.  <​
[Link]
45
 "Configuring slapd ‐ OpenLDAP." 2007. <​
[Link]
 
 
Conceptos básicos de administración Linux 
 

# ldapsearch ‐Q ‐LLL ‐Y EXTERNAL ‐H ldapi:/// ‐b cn=config dn objectClass 
o 
$ ldapsearch ‐LLL ‐h localhost ‐xD "cn=super,cn=config" ‐W  ‐b "cn=config" dn objectClass 
dn: cn=config 
objectClass: olcGlobal 
 
dn: cn=schema,cn=config 
objectClass: olcSchemaConfig 
 
dn: cn={0}core,cn=schema,cn=config 
objectClass: olcSchemaConfig 
 
dn: cn={1}cosine,cn=schema,cn=config 
objectClass: olcSchemaConfig 
 
dn: cn={2}nis,cn=schema,cn=config 
objectClass: olcSchemaConfig 
 
dn: olcDatabase={‐1}frontend,cn=config 
objectClass: olcDatabaseConfig 
objectClass: olcFrontendConfig 
 
dn: olcDatabase={0}config,cn=config 
objectClass: olcDatabaseConfig 
 
dn: olcDatabase={1}monitor,cn=config 
objectClass: olcDatabaseConfig 
 
dn: olcDatabase={2}hdb,cn=config 
objectClass: olcDatabaseConfig 
objectClass: olcHdbConfig 

Los  dos comandos son equivalentes. El  primero lo ejecuta el  ​ root  del sistema en el que está instalado 

OpenLDAP  y toma sus credenciales para  permitir  el acceso al contenido del árbol de configuración. En 
el  segundo  lo  ejecuta  un  usuario  que  ha  sido  definido  como  el  ​root  del  servidor  LDAP,  en  este  caso 
cn=super,cn=config​
“​ ”,  y  que  tiene  la  capacidad  para  modificar  su  configuración.  Vemos  que,  en 
lugar  de  un  fichero  de  texto  de   configuración  ,  como  es  habitual  en  muchos  servicios  en  Linux,  se 
emplea  un  DIT donde cada “sección” del fichero  de configuración es una entrada del directorio y dicha 
entrada  pertenece  a  una  clase  particular  cuyos  atributos  son  los  necesarios  para fijar  los parámetros 
necesarios  en  la  configuración  del  servicio  LDAP.  Estos  atributos  constituyen  un  conjunto  bastante  
numeroso  y  no  entraremos en detalle en ellos. Por ahora nos basta con saber que para la configuración 
de  OpenLDAP se guardan los parámetros, aprovechando  los  propios conceptos de un directorio,  en los 
atributos  de   las  entradas  de  un  directorio  particular,  con  base  o  sufijo  igual  a  “cn=config”.  Además, 
podemos  ver  que  los  atributos  o  clases  de  objetos  comienzan  con  “olc”  (​ on‐line  configuration​ )  para 
asociarlos fácilmente a la configuración dinámica.  
Si  trasladamos  la  información  del  ejemplo  anterior  a  un  gráfico  podría quedar  de  la siguiente 
forma: 
 
 
Conceptos básicos de administración Linux 
 

 
 
Vamos a describir brevemente la finalidad de cada entrada: 
● cn=config​
:  Las  directivas de configuración en esta  entrada,  esto  es, los atributos de la misma, 
afectan a  todo el servidor LDAP y están principalmente relacionadas con la conexión y no con la 
base de datos. Ejemplo (no es relevante para nosotros el significado de los atributos): 
dn: cn=config 
objectClass: olcGlobal 
cn: config 
olcIdleTimeout: 30 
olcArgsFile: /var/run/openldap/[Link] 
olcPidFile: /var/run/openldap/[Link] 
olcTLSCACertificatePath: /etc/openldap/certs 
olcTLSCertificateFile: "OpenLDAP Server" 
olcTLSCertificateKeyFile: /etc/openldap/certs/password 

● cn=schema,cn=config​
:  Contiene  las  definiciones  relacionadas  con  los  tipos  de  atributos  y 
clases  de  objetos.  Suele  estar  dividido  en  varias  entradas  agrupando  las  clases  de   objetos 
similares. Ejemplo: 
dn: cn=schema,cn=config 
objectClass: olcSchemaConfig 
cn: schema 
olcObjectIdentifier: OLcfg [Link].4.1.4203.1.12.2 
olcObjectIdentifier: OLcfgAt OLcfg:3 
olcObjectIdentifier: OLcfgGlAt OLcfgAt:0 
... 
dn: cn={0}core,cn=schema,cn=config 
objectClass: olcSchemaConfig 
cn: {0}core 
olcAttributeTypes: {0}( [Link] NAME 'knowledgeInformation' DESC 'RFC2256: kno 
 wledge information' EQUALITY caseIgnoreMatch SYNTAX [Link].4.1.1466.115.121. 
 1.15{32768} ) 
… 
olcObjectClasses: {4}( [Link] NAME 'person' DESC 'RFC2256: a person' SUP top  
 STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $  
 description ) ) 
 
 
Conceptos básicos de administración Linux 
 

● olcDatabase={?}frontend,cn=config​
:  El  índice entre llaves se usa para  distinguir  entradas 
del  mismo  tipo.  Incluye  opciones  que  deben  ser  aplicadas  al  resto  de  entradas  del  tipo 
olcDatabaseConfig. 
● olcDatabase={?}config,cn=config​ slapd​
: Contiene la configuración del demonio ​ . Ejemplo: 
dn: olcDatabase={0}config,cn=config 
objectClass: olcDatabaseConfig 
olcDatabase: {0}config 
olcAccess: {0}to * by [Link]="gidNumber=0+uidNumber=0,cn=peercred,cn=external 
 ,cn=auth" manage by * none 
olcRootDN: cn=super,cn=config 
olcRootPW: {SSHA}5W5GGFDdLTZOHDMZ2oPJGFDSJT/d+lwHCzxsLgOt0/DQJGR 

En  este caso, sí nos detendremos  en los  atributos  de configuración,  aunque no  en su sintaxis, tan solo 

en  su utilidad  o significado general. “olcAccess”  especifica  las ACLs que se comentaron anteriormente. 
En  este  caso,  si  de  forma   externa  alguien  se  valida  como  ​ root  (uid=gid=0)  tiene  acceso  de  gestión 
manage​
(​ ), que fue la  forma de acceso utilizada en primer lugar en  el ejemplo de búsqueda en el árbol 
de  configuración. Los  dos últimos  atributos  corresponden al  ​ root  ​
del servidor LDAP, y fueron utilizados  
en  el ejemplo como  segunda  forma  de búsqueda en árbol de  configuración. A ese usuario, definido en 
este caso particular  por el  DN: c ​n=super,cn=config​ ,  no  se le aplican las ACLs y puede gestionar todo 
el  servidor,  por  ejemplo  cambiando  la  configuración  de forma dinámica,  añadiendo  clases al ​ schema​ , 
nuevos DIT de información, etc. 
● olcDatabase={?}monitor,cn=config​
:  permite  monitorizar  en  tiempo  real  estadísticas  del 
árbol LDAP, uso, búsquedas, conexiones, etc. 
● olcDatabase={?}hdb,cn=config​ :  Instancia  de base de  datos para un dominio  particular.  En 
Hierarchical​
este caso se trata  de una  base de datos  HDB, esto es, una  variante jerárquica  (​ ) de 
BDB (​Berkeley DB​). Ejemplo: 
dn: olcDatabase={2}hdb,cn=config 
objectClass: olcDatabaseConfig 
objectClass: olcHdbConfig 
olcDatabase: {2}hdb 
olcDbDirectory: /var/lib/ldap 
olcSuffix: dc=mycompany,dc=com 
olcAccess: {0}to [Link]="ou=level1,dc=mycompany,dc=com" attrs=cn by self write 
olcAccess: {1}to [Link]="ou=level1,dc=mycompany,dc=com" by anonymous auth 
olcAccess: {2}to * by users read 
olcRootDN: cn=admin,dc=mycompany,dc=com 
olcRootPW: {SSHA}8HNCoHFvld0scs366LtkfrhI54ThE4C3q00bZyIRhUF 
olcDbIndex: objectClass eq,pres 
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub 

Aquí también nos vamos  a  detener en  los  significados  generales  de  algunos atributos. Primero, vemos 

que aquí ya estamos definiendo la raíz  o sufijo  de un  árbol de información (​ olcSuffix​ ), donde vamos 
a  almacenar  las  entradas  de  nuestro  dominio.  Además,  definimos  quién va a ser  el administrador de 
ese  DIT  (​cn=admin,dc=mycompany,dc=com​ password​
)  y  cuál  va  a  ser  su  ​ .  Es  importante  que 
distingamos entre el administrador del servidor OpenLDAP, visto anteriormente, y el de cada uno de los 
DIT (repositorios de información de la organización no de configuración) que incluyamos en el servidor. 
Por  ejemplo,  el  administrador  definido  aquí  podrá  añadir,  modificar,  eliminar entradas  del  directorio 
que  él  controla,  pero  no  podrá  administrar  otros  DITs  de  otros  dominios  que  residan  en  el  mismo 
schema​
servidor,  ni modificar el ​ , ni cambiar la configuración del servidor. Además, sin entrar en detalle, 
pues va más allá del alcance de este curso básico,  podemos fijarnos en las ACLs definidas para este DIT. 
Brevemente,  en  las  líneas  que  comienzan  con  “olcAccess”,  se indica que  las entradas  cuyo  padre  sea 
 
 
Conceptos básicos de administración Linux 
 

ou=level1,dc=mycompany,dc=com​
“​ ”  pueden  modificar  (​ write​)  su  propio  (​ self​
)  atributo  “cn”, 
asumiendo que son usuarios. Esos usuarios también pueden autenticarse en el sistema, que emplea un 
usuario  ​
anonymous  en  la  primera  fase  del  proceso.  Por  último,  el  resto  de  usuarios  (*)  pueden  leer 
read​
(​ ) el contenido de todo (*) el directorio.  
 

3.3.2. Ejemplo 
Vamos  a realizar un ejemplo en  el que se definirán  nuevos  tipos  de atributos, nuevas clases de 
objetos  y  se  crearán  algunas  entradas  en  un  directorio  de  información.  No  se  trata  de  realizar  un 
ejemplo  detallado  y  siguiendo  todos  los  estándares,  pero  sí  de  poner  en  práctica  los  conceptos más 
básicos que hemos visto en esta sección para fijar los conceptos. 
Supongamos  que  en  nuestra  compañía  ([Link]) los jefes están organizando  una liga 
de  baloncesto interna. Nos piden que  creemos  una base de  datos  con los  participantes, que  contenga 
algunos  campos  para  facilitar  la  organización  del  campeonato.  Obligatoriamente   todo  jugador  debe 
nick​
tener  un  apodo  (​ alt​
)  que  aparezca  en  las  camisetas,  una  altura  (​ )  para  facilitar  la  tarea  del 
entrenador y el equipo al  que pertenece  dentro de la liguilla (​team​ ). Opcionalmente puede aparecer la 
edad del jugador en años (​ agnos​ ).  
Nosotros,  como   administradores  proponemos  utilizar  el  directorio  que  la  compañía  tiene  ya 
funcionando, añadiendo al ​schema​  los atributos y clases de objetos necesarios y los jugadores.  
schema46 ​
En  primer lugar podríamos crear un archivo LDIF con los cambios que queremos realizar en el ​ . 
Por ejemplo: 
$ cat cambioschema_basket.ldif  
dn: cn=basket,cn=schema,cn=config 
objectClass: olcSchemaConfig 
cn: basket 
olcAttributeTypes: ( [Link].10 NAME 'nick' DESC 'nombre jugador'  
  EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch  
  SYNTAX [Link].4.1.1466.[Link] SINGLE‐VALUE ) 
olcAttributeTypes: ( [Link].11 NAME 'team' DESC 'equipo baloncesto'  
  EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch  
  SYNTAX [Link].4.1.1466.[Link] SINGLE‐VALUE ) 
olcAttributeTypes: ( [Link].12 NAME 'alt' DESC 'altura jugador centimetros'  
  EQUALITY integerMatch SYNTAX [Link].4.1.1466.[Link] SINGLE‐VALUE ) 
olcAttributeTypes: ( [Link].13 NAME 'agnos' DESC 'edad jugador agnos'  
  EQUALITY integerMatch SYNTAX [Link].4.1.1466.[Link] SINGLE‐VALUE ) 
olcObjectClasses: ( [Link].2 NAME 'player' DESC 'Jugador Liga Interna' SUP top AUXILIARY  
  MUST ( nick $ team $ alt ) MAY agnos) 
olcObjectClasses: ( [Link].3 NAME 'visitante' DESC 'Jugador Visitante' SUP top STRUCTURAL  
  MUST cn) 

Hemos  supuesto que a  nuestra compañía le  han asignado los  OIDs que comienzan  por 4.5, así  que los 

OIDs  de  todos  los  tipos  de  atributos  y  clases  de  objetos  poseen  dicho  prefijo.  De  esa  manera  no 
utilizamos  valores que ya estuviesen  en uso. Los  atributos  se  han creado copiando otros de  propósito 
similar  que  ya  estaban  en  el  ​ schema  con  el  fin  de  simplificar  la  selección  de  las  sintaxis 
correspondientes.  Vemos  que  tanto  “nick” como  “team”  son cadenas de texto y “alt” y “agnos” (se ha 
evitado  la  ñ  por  si  causaba  algún  problema) son  números enteros. A  continuación se ha definido una 
nueva clase, “player”, que contiene todos estos atributos, los tres primeros serían obligatorios para una 
entrada de  este tipo y el último sería opcional. Además, podemos observar que la clase se ha declarado 
46
 "Schema Specification ‐ OpenLDAP." 2007.  <​
[Link]
> 
 
 
Conceptos básicos de administración Linux 
 

de  tipo  auxiliar. La razón  por la que nos hemos decantado por  esta solución (que  no es  única  ni  tiene 

que  ser  la  mejor)  es  la  siguiente:  queremos  aprovechar  las  entradas  de  los   empleados  que,  en  los 
ejemplos  vistos  anteriormente, ya pertenecen a la clase estructural “account”. Como la clase “player” y 
la  clase  “account”  no  desciende  una  de  la  otra,  las  entradas  que  creemos  no  podrían  pertenecer  a 
ambas  si  las  dos  son   estructurales. El  problema  entonces lo tenemos para  dar de  alta a  los jugadores 
invitados,  ya  que  no  es  lógico  que  creemos  entradas  en  el  DIT de  tipo “account”  si  esas  personas  no 
trabajan para la  empresa. Tampoco  una entrada puede pertenecer sólo a una clase auxiliar, así que no 
podemos declarar entradas  de la clase “player” exclusivamente. Por todo esto, nos hemos inventado la 
clase  “visitante”,  de  tipo  estructural  y  que  posee  un  solo  atributo  que  no hemos creado  nosotros  ya 
que nos sirve con  el habitualmente utilizado  “cn” o  “common  name”.  Para  añadir todas estas  nuevas 
definiciones al ​ schema​  lo hacemos de la siguiente forma: 
ldapadd ‐h localhost ‐xD "cn=super,cn=config" ‐W  ‐f cambioschema_basket.ldif 
 
Enter LDAP Password:  
adding new entry "cn=basket,cn=schema,cn=config" 

Hay  que  notar  que  lo hemos realizado  utilizando  el usuario  “​ cn=super,cn=config​ ”  que recordemos 

era  el único con  permisos  para cambiar  la configuración del servidor OpenLDAP, incluyendo el ​ schema. 
Realmente,  como  se  ha  comentado  anteriormente,  habría  otra  forma  de  realizarlo:  actuando  como 
root  de  la  máquina  en  la  que  estuviese   corriendo  el  servicio  ​
slapd  y  aprovechando  la  ACL declarada 
para accesos externos, esto es: 
ldapadd ‐Y EXTERNAL ‐H ldapi:/// ‐f cambioschema_basket.ldif  

Si  ahora  realizásemos  una  búsqueda  de  las  entradas  presentes  en  el  DIT  de  configuración, 
obtendríamos algo como lo siguiente:  
$ ldapsearch ‐LLL ‐h localhost ‐xD "cn=super,cn=config" ‐W  ‐b "cn=config" dn 
Enter LDAP Password:  
dn: cn=config 
dn: cn=schema,cn=config 
dn: cn={0}core,cn=schema,cn=config 
dn: cn={1}cosine,cn=schema,cn=config 
dn: cn={2}nis,cn=schema,cn=config 
dn: cn={3}basket,cn=schema,cn=config 
dn: olcDatabase={‐1}frontend,cn=config 
dn: olcDatabase={0}config,cn=config 
dn: olcDatabase={1}monitor,cn=config 
dn: olcDatabase={2}hdb,cn=config 

shema​
donde se ha destacado la nueva entrada del ​ . El árbol quedaría de la siguiente forma: 

 
 
 
Conceptos básicos de administración Linux 
 

 
Con  el ​
schema ya modificado, podemos  pasar a introducir las  entradas que deseemos en el directorio. 
Un ejemplo de fichero LDIF creado para facilitar dicha tarea sería: 
$ cat prueba_basket.ldif  
dn: ou=jefes,dc=mycompany,dc=com 
objectClass: organizationalUnit 
ou: jefes 
 
dn: uid=remigio,ou=jefes,dc=mycompany,dc=com 
uid: remigio 
objectClass: posixAccount 
objectClass: account 
cn: remigio 
loginShell: /bin/bash 
uidNumber: 2056 
gidNumber: 2056 
homeDirectory: /home/remigio 
 
dn: uid=rodolfo,ou=jefes,dc=mycompany,dc=com 
uid: rodolfo 
objectClass: posixAccount 
objectClass: account 
objectClass: player 
cn: RodolfoGarcia 
loginShell: /bin/bash 
uidNumber: 2057 
gidNumber: 2057 
homeDirectory: /home/rodolfo 
nick: Curry 
agnos: 45 
alt: 184 
team: jefazos 
 
dn: ou=visitantes,dc=mycompany,dc=com 
objectClass: organizationalUnit 
ou: visitantes 
 
dn: cn=rigoberto,ou=visitantes,dc=mycompany,dc=com 
objectClass: visitante 
objectClass: player 
cn: rigoberto 
nick: LeBron 
alt: 203 
team: jefazos 

La  primera entrada (recordemos que las  entradas en  un archivo LDIF están separadas por una línea en 

blanco)  corresponde  a  una  unidad   organizativa,  donde  estarán  los  “jefes”  de  la compañía.  En primer 
lugar creamos  la entrada correspondiente  a “remigio” que es jefe pero no va a jugar en ningún equipo, 
por  lo que  no  es  necesario que pertenezca a la clase “player”.  Luego creamos a “rodolfo”, que sí jugará 
en  el equipo  “jefazos” así que,  además  de  pertenecer a las clases “account” y “posixAccount” para  que 
pueda  ser  validado  en  los  sistemas  de  la  empresa y  realizar  su trabajo sin  problemas,  pertenece a  la 
clase  “player”,  lo  que  permite definir los atributos “nick”, “alt”, “team” y “agnos”. Este último de forma 
opcional.   Finalmente  creamos  otra  unidad  organizativa,  algunas  veces  vistas  como  carpetas  para 
 
 
Conceptos básicos de administración Linux 
 

ordenar  nuestras  entradas  en  el  directorio,  para  incluir  a  los  jugadores  invitados.  La  hemos 
denominado  “visitantes”.  En  ella  creamos  la  entrada  de  uno  de  esos  visitantes,  “rigoberto”,  que 
pertenece a las clases “visitante” y “player”. 
Finalmente debemos introducir esas entradas en el directorio, por ejemplo mediante: 
$ ldapadd ‐xD "cn=admin,dc=mycompany,dc=com" ‐W ‐f prueba_basket.ldif  
Enter LDAP Password: 

En  este  caso  es  importante  observar  que  lo  realiza  el  administrador  del  árbol  del  dominio 
dc=mycompany,dc=com​
“​ cn=admin,dc=mycompany,dc=com​
”, es decir “​ ”, pues es quien tiene permisos 
manage​
para gestionar (​ ) dicho DIT.  
 
 
   
 
 
Conceptos básicos de administración Linux 
 

4. NFS (Network File System) 
 
El  protocolo  NFS,  Network  File  System,  permite  que   un  servidor  pueda  compartir  diversas 
partes  de  su  árbol  de  directorios   con  ordenadores  cliente  a  través  de  redes  heterogéneas.  Fue 
introducido por primera vez  por Sun Microsystems47  en 1984 para el soporte de  sistemas sin disco, que 
mantenían  toda  su  información  en  un  servidor.  Actualmente  está  soportado  en  diferentes  sistemas 
operativos como Linux, Mac OS X, Windows, Unix, etc. 
Los  clientes,  de  forma  remota,  pueden   “montar”  los  sistemas  de  ficheros a través de  la  red  e 
interactuar  con ellos como  si  los hubíesemos  montado desde un dispositivo  de almacenamiento local. 
Esto  permite  a  los  administradores  concentrar  los  recursos  de  almacenamiento  en  servidores  
especializados.  Esta  centralización  de los datos proporciona algunas ventajas. Por una parte, reduce las 
necesidades  de  almacenamiento  ya  que  la  información  necesaria  para  varios  usuarios  no  tiene  que 
estar  repetida  en  diferentes  ordenadores  personales.  Además,  simplifica  la  administración,  ya  que la 
información  debe  ser  mantenida  en  un  solo  espacio,  facilitando,  entre  otras,  las  tareas  de  ​
back‐up. 
Asimismo,  se  mejora la consistencia de la  información ya que los distintos clientes acceden a la misma 
información compartida  cuando es necesario.  Por otro lado,  los  usuarios podrían  acceder  a  sus datos 
independientemente del ordenador cliente en el que trabajen. 
En  la  siguiente  figura   se  esquematiza  el  concepto  de  montaje  remoto  de  una  parte  del 
directorio de archivos: 
 

 
En  este  caso  un  servidor  NFS ha exportado (compartido)  una parte del árbol de directorios, tomando 
como  base o  raíz  “datos”. La  máquina  cliente  NFS  desea  montarlo en el directorio local “home”. Por lo 
tanto  los usuarios  de dicho  cliente  accederán  a los  archivos y directorios contenidos en “/home” como 
si estuviesen en un sistema de almacenamiento local.  
Veamos  un ejemplo basado en lo que nos encontraríamos al acceder a un ordenador del Centro 
de Cálculo de la ESIT. Si deseamos ver los sistemas de archivos disponibles: 

47
 "Oracle and Sun Microsystems | Strategic Acquisitions | Oracle." 2014. 21 Feb. 2016 <​
[Link]
> 
 
 
Conceptos básicos de administración Linux 
 

$df ‐h ‐T 
[Link]               Tipo     Tamaño Usados  Disp Uso% Montado en 
/dev/sda1                ext4       113G    15G   93G  14% / 
rala:/scratch            nfs         40G   177M   38G   1% /scratch 
rala:/export/ubuntu14.04 nfs        1,7T   557G  1,1T  35% /soft 
//rala/albano            cifs       1,7T   557G  1,1T  35% /home/albano/datos/[Link] 

Se  ha  añadido la  opción  “‐T” para que muestre el tipo de sistema de archivos. Vemos que  el disco local, 

concretamente  su primera partición, está montado  en la  raíz  (/).  Además hay tres directorios remotos 
que  no  residen  en  la  máquina  local,  sino  en  un  servidor  cuyo  nombre  es  “rala”.  Los  dos  primeros 
corresponden  al  protocolo  NFS.  En  este  caso  vemos  que  en  el  servidor  se  ha  compartido  la  carpeta  
“/scratch”  y el  cliente la  ha  montado dentro de su árbol de directorios en el punto “/scratch”. Además, 
el  servidor  ha exportado el directorio  “/export/ubuntu14.04” y el cliente  lo ha montado  en  “/soft”. El 
otro protocolo CIFS48  49  no nos preocupa por ahora.  
Si accedemos al directorio “/soft” de la máquina cliente y listamos su contenido: 
$ ls ‐lh /soft 
total 164K 
drwxr‐xr‐x 2 root root 4,0K feb 17 09:42 actualiza‐linux 
drwxr‐xr‐x 2 root root 4,0K dic 14 12:38 bin 
drwxr‐xr‐x 3 root root 4,0K dic  4 10:49 conf 
‐rw‐r‐‐r‐‐ 1 root root  301 oct  7  2014 configuar‐cliente‐ldap 
‐rwxr‐xr‐x 1 root root 2,4K may  4  2015 hadoop 
... 

no apreciamos ninguna diferencia  respecto  a los  sistemas de archivos locales, y  podemos acceder a los 

archivos y carpetas de la misma forma (con algunas particularidades que veremos a continuación). 
Actualmente  la  versión  de  NFS  más  utilizada  y soportada por  los sistemas es la  4,  NFSv4. Esta 
versión  incluye  algunas  mejoras sobre  sus  antecesoras. Como protocolo  de transporte emplea  TCP de 
forma  exclusiva e integra algunas funciones que antes  dependían de otros procesos o  servicios,  limita 
la  comunicación   a  través  de  RPC50   (Remote  Procedure  Calls)  utilizando  en   exclusiva  el  puerto  2049 
(configurable),  lo  que  simplifica  la  gestión  de  los  puertos   en  ​
firewalls  y  dispositivos  NAT51 .   Además, 
NFSv4  es  un  protocolo  basado  en  estados,  de  forma  que  tanto  el  cliente  como  el  servidor  tienen 
información  acerca  de  los archivos abiertos  y  los bloqueos correspondientes. Además, ha solucionado 
problemas de seguridad permitiendo su interacción con sistemas de autenticación más robustos. 
Veamos  a  continuación  la  configuración  básica  del  servidor  y  del  cliente  para  que  puedan 
realizarse, por un parte, la exportación de las carpetas y, por otra, el montaje remoto de las mismas.  
 
4.1. Configuración del servidor 
La  configuración  del  servidor  NFS  es  relativamente sencilla. Por supuesto el  servicio NFS debe 
estar  instalado  y  activo.  Por  lo  demás,  sólo  es  necesario  declarar  qué  partes  del  árbol de  directorios 
queremos  exportar.  El  fichero  “​ /etc/exports​ ”  recoge  en formato de  texto  los directorios que están 
exportados,  qué  máquinas  cliente  tienen  acceso a ellos y de  qué forma.  Se trata  básicamente  de  una 
ACL en la que cada línea corresponde a un directorio exportado y que sigue el siguiente formato: 

48
 "Common Internet File System ‐ TechNet ‐ Microsoft." 2015. <​[Link] > 
49
 "Server Message Block ‐ Wikipedia, the free encyclopedia." 2011. <​[Link]
> 
50
 "Remote procedure call ‐ Wikipedia, the free encyclopedia." 2011. <​[Link]
51
 "Network address translation ‐ Wikipedia, the free encyclopedia." 2011. 
<​[Link] > 
 
 
Conceptos básicos de administración Linux 
 

punto‐exportado  cliente1(lista‐de‐opciones) cliente2(lista‐de‐opciones) 
... 
El  primer  parámetro  es  la  ruta  absoluta  del  directorio  que  queremos  exportar.  Los  clientes  hacen 
referencia  a  las  IPs  o  los  nombres  de  las  máquinas  que  pueden  montar  los  directorios  exportados. 
Finalmente las opciones marcan las características de la exportación. Las más destacadas son: 
● ro(rw)​
:  indica  si  el  directorio  (y  el   árbol  de carpetas  y archivos que  contiene)  será exportado 
para  acceso  de  sólo  lectura  (ro)  o  para  lectura/escritura  (rw).  Esta  última  opción  es  el 
comportamiento  por  defecto.  Lógicamente  habría  que  tener  también  en  cuenta  los  permisos 
que  cada  usuario  o  los   grupos  a  los  que  pertenece  tuviesen  en  el  sistema  de  archivos  del 
servidor,  prevaleciendo  el  más  restrictivo  de  los  dos.  Por  ejemplo,  aunque  en  el  servidor  un 
archivo  tuviese  permisos  de  escritura  para  un  usuario,  éste  no  podría  modificarlo  desde  la 
máquina cliente si el directorio donde reside hubiese sido exportado con la opción RO.   
● secure(insecure)​ :  La  opción  “secure”  (la  establecida  por  defecto)  requiere que  los accesos 
remotos  se  generen  en  un  puerto  con  privilegios,  esto  es  un  puerto por  debajo  del  1024 que 
sólo un proceso que corra con privilegios de ​ root​ puede utilizar. 
● sec=mode​ :  Es  el  tipo  de  seguridad  utilizado  para  acceder  a archivos exportados.  Por ejemplo: 
sys (AUTH_SYS), krb5, krb5i, krb5p, lkey, lkeyi, lkeyp, spkm, spkmi, pkmp. Por defecto es “sys”.  
● root_squash (no_root_squash)​ : Mapea  las peticiones realizadas como ​ root desde el cliente 
(UID=GID=0)  como  si  viniesen del usuario  “nfsnobody”  (UID=GID=65534) para  evitar que  actúe  
con  los  privilegios  del  ​ root  del  cliente  sobre los  archivos  del  servidor.  Si  se definen  además las 
opciones  “anonuid”  y  “anongid”  se   mapearían  los  accesos  como  ​ root  desde  cliente  a  estos 
identificadores de usuario y grupo en el servidor. La opción por defecto es “​ root_squash​ ”. 
● no_all_squash (all_squash)​ :  La  segunda  opción, que  no  es  la elegida por defecto, mapea 
todos los usuarios  a “nfsnobody” o a “anonuid” si estuviese definido.  
● anonuid=xxx  o  a ​nongid=yyy​ :  Asigna  el  UID  y el GID de la  cuenta de  acceso anónima a xxx e 
yyy, respectivamente.   
Veamos  un  ejemplo.  Supongamos  que  en  el  servidor,  tenemos  la  siguiente  estructura  de 
archivos y directorios en “/exportdir”: 
# pwd 
/exportdir 
# tree ‐p ‐u ‐g 
. 
├── [drwxrwsr‐x root     asesores]  dir_1 
│   ├── [‐rw‐rw‐r‐‐ marta    asesores]  a_1.txt 
│   └── [drwxrwsrwx marta    asesores]  dir_1_1 
│       └── [‐rw‐rw‐r‐‐ marta    asesores]  a_1_1.txt 
├── [drwxrwsr‐x root     asesores]  dir_2 
│   ├── [‐rw‐rw‐r‐‐ marta    asesores]  b_1.txt 
│   ├── [drwxrwsr‐x marta    asesores]  dir_2_1 
│   │   ├── [‐rw‐rw‐r‐‐ marta    asesores]  b_2_1a.txt 
│   │   └── [‐rw‐rw‐r‐‐ marta    asesores]  b_2_1b.txt 
│   └── [drwxrwsr‐x marta    asesores]  dir_2_2 
│       └── [‐rw‐rw‐r‐‐ marta    asesores]  b_2_2a.txt 
└── [drwxrwsr‐x root     asesores]  dir_3 
    ├── [‐rw‐rw‐r‐‐ manolo   asesores]  c_3.txt 
    └──​  ​
[drwxrwsr‐x manolo   asesores]  dir_3_1 
        ├── [‐rw‐rw‐r‐‐ manolo   asesores]  c_3_1.txt 
        └── [‐rw‐rw‐r‐‐ manolo   asesores]  c_3_2.txt 
 
 
Conceptos básicos de administración Linux 
 

De  todo  el  sub‐árbol  mostrado,  en  negrita  y   con  distinto  color  se  resaltan  aquellas  partes  que 
queremos compartir. Para ello un ejemplo de archivo de exportación sería: 
# cat /etc/exports 
/exportdir/dir_1 [Link]/24(rw) 
/exportdir/dir_3/dir_3_1 [Link](ro,all_squash,anonuid=3333,anongid=6666) [Link](rw) 

/exportdir/dir_1​
En  este caso el  directorio “​ ” lo compartiremos  en modo lectura/escritura con todas  
las  máquinas  cliente  que  pertenezcan  a  la  red  [Link]/24.  Además  la  carpeta 
/exportdir/dir_3/dir_3_1​
“​ ”  la  compartimos  sólo  con  dos  máquinas cliente,  la 221, en  modo  sólo 
lectura  y haciendo  que  todos los  usuarios sean  mapeados al  UID=3333,GID=6666,  y  la 222, con acceso 
de  lectura/escritura.  Es  importante  recalcar  que  se  especifica  el  nombre  o  IP   de  las  máquinas  que  
tienen  acceso  (permiso  para  montar)  no  de  los  nombres  de  los  usuarios.  Además,  se  debe  tener  en 
cuenta que  al exportar un  directorio  se exporta toda la rama del árbol  que cuelga bajo él. Podemos ver 
las carpetas exportadas con el comando “exportfs”. 
# exportfs 
/exportdir/dir_3/dir_3_1 
[Link] 
/exportdir/dir_3/dir_3_1 
[Link] 
/exportdir/dir_1 
[Link]/24 

Podríamos también obtener las opciones con las que se han exportado: 
# exportfs ‐s 
/exportdir/dir_3/dir_3_1 
[Link](ro,wdelay,root_squash,all_squash,no_subtree_check,anonuid=3333,anongid=6666,sec=sys,ro,
secure) 
/exportdir/dir_3/dir_3_1 
[Link](rw,wdelay,root_squash,no_subtree_check,sec=sys,secure,no_all_squash) 
/exportdir/dir_1  [Link]/24(rw,wdelay,root_squash,no_subtree_check,sec=sys,secure,no_all_squash) 

Vemos que aunque no hayamos especificado todas las opciones, se toman los valores por defecto.  
Podemos  también  observar  en  el  ejemplo  anterior  que  la  seguridad  por  defecto  es  “sys”, 
abreviatura de  AUTH_SYS.   
 
4.2. Montaje en los clientes 
Los  sistemas  de  archivos  NFS  son  montados  de  la  misma  forma  que  los  sistemas  de  archivos 
locales.  El  comando  “mount”  distingue  la  notación  ​ servidor:directorio  para  indicar  que  se 
encuentra en un servidor remoto.  
Supongamos,  siguiendo  con  el  ejemplo  del  servidor,  que  queremos  montar  las  carpetas 
/import/serv1​
exportadas en nuestro cliente. Nuestra estructura de directorios en “​ ” es 
# tree /import/serv1 
/import/serv1 
|‐‐ datos_as 
`‐‐ facturas_as 

que  es  precisamente  donde  queremos  montar,  respectivamente,  las  dos  carpetas  exportadas  en  el 
servidor. Para ello podemos usar el comando “mount”: 
 
 
Conceptos básicos de administración Linux 
 

# mount ‐t nfs [Link]:/exportdir/dir_1 serv1/datos_as 
# mount ‐t nfs [Link]:/exportdir/dir_3/dir_3_1 serv1/facturas_as/ 

donde  podemos  observar  que  se  especifica  la  IP  (podría  ser  el  nombre)  del  servidor  y  el  directorio 
exportado,  indicando en  qué  punto  del  árbol de  directorios  local se quiere montar.  Se ha  especificado 
que el  tipo  de sistema de archivos es “nfs” aunque en la mayoría de los casos no es necesario. Además, 
podrían  especificarse  otras  opciones  para  el  montaje,  como  que  se  montara  en  modo  solo  lectura 
aunque  se  hubiese exportado de otra  forma,  que  no se hagan efectivos los permisos especiales setGID 
o  setUID  en  los  directorios  montados,  que  no  se pueda  acceder a  los archivos especiales  asociados a 
dispositivos, etc. Podemos ver las características de los montajes del ejemplo con:  
# mount | grep exportdir 
[Link]:/exportdir/dir_1 on /import/serv1/datos_as type nfs4 
(rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2
,sec=sys,clientaddr=[Link],local_lock=none,addr=[Link]) 
[Link]:/exportdir/dir_3/dir_3_1 on /import/serv1/facturas_as type nfs4 
(rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2
,sec=sys,clientaddr=[Link],local_lock=none,addr=[Link]) 

Las  características  mostradas  van  más  allá  de  una  introducción  básica  a  NFS.  Puede  obtenerse  más 
información mediante la ayuda (​ man​ ) de “mount” y “nfs”. 
Una  vez montados los sistemas  NFS,  los usuarios  del  equipo local pueden utilizar las carpetas y 
archivos. La estructura quedaría de la siguiente forma: 
# tree ‐p /import/serv1 
/import/serv1 
|‐‐ [drwxrwsr‐x]  datos_as 
|   |‐‐ [‐rw‐rw‐r‐‐]  a_1.txt 
|   `‐‐ [drwxrwsrwx]  dir_1_1 
|       `‐‐ [‐rw‐rw‐r‐‐]  a_1_1.txt 
`‐‐ [drwxrwsr‐x]  facturas_as 
    |‐‐ [‐rw‐rw‐r‐‐]  c_3_1.txt 
    `‐‐ [‐rw‐rw‐r‐‐]  c_3_2.txt 

Vemos   que  el  contenido  de  cada  una  de  las  carpetas  corresponde  con las  exportadas en  el servidor. 
Cada  una  de  las  carpetas  exportadas  las  podemos  montar  en  el  punto  que  deseemos,  creando  una 
estructura que sea de utilidad para los usuarios. 
En  NFSv4  el  servidor  guarda un  pseudo  sistema  de archivos con  todas  las carpetas que  se han 
exportado,  descartando  las  restantes,  por  lo  que  el  cliente  simplemente  podría  montar la  raíz  de las 
carpetas exportadas para acceder todo lo que se ha compartido en el servidor. Por ejemplo: 
# mount ‐t nfs [Link]:/exportdir /import/from_exportdir/ 
# tree ‐p /import/from_exportdir/ 
/import/from_exportdir/ 
|‐‐ [drwxrwsr‐x]  dir_1 
|   |‐‐ [‐rw‐rw‐r‐‐]  a_1.txt 
|   `‐‐ [drwxrwsrwx]  dir_1_1 
|       `‐‐ [‐rw‐rw‐r‐‐]  a_1_1.txt 
`‐‐ [drwxrwsr‐x]  dir_3 
    `‐‐ [drwxrwsr‐x]  dir_3_1 
        |‐‐ [‐rw‐rw‐r‐‐]  c_3_1.txt 
        `‐‐ [‐rw‐rw‐r‐‐]  c_3_2.txt 

En  lugar  de  montar  las  dos  carpetas  por  separado,  como  en  el  ejemplo  anterior,  se  ha  montado 
directamente  la  carpeta  “/exportdir”   del  servidor  en  el  directorio  local  “from_exportdir”.  Cuando 
 
 
Conceptos básicos de administración Linux 
 

vemos  lo  que  se  ha  montado  se  puede  observar  que  sólo  aparecen  los  contenidos  de  las  carpetas 
exportadas  y  las   rutas  para  llegar  hasta   ellas,  pero  no  aparece  el  contenido  de  las  que  no  han  sido 
exportadas explícitamente.  
Se  podría  incluso montar  la raíz del servidor y aparecerían sólo los directorios compartidos y las  
rutas hasta ellos: 
# mount ‐t nfs [Link]:/  /import/from_root 
# tree ‐p /import/from_root 
/import/from_root 
`‐‐ [drwxr‐xr‐x]  exportdir 
    |‐‐ [drwxrwsr‐x]  dir_1 
    |   |‐‐ [‐rw‐rw‐r‐‐]  a_1.txt 
    |   `‐‐ [drwxrwsrwx]  dir_1_1 
    |       `‐‐ [‐rw‐rw‐r‐‐]  a_1_1.txt 
    `‐‐ [drwxrwsr‐x]  dir_3 
        `‐‐ [drwxrwsr‐x]  dir_3_1 
            |‐‐ [‐rw‐rw‐r‐‐]  c_3_1.txt 
            `‐‐ [‐rw‐rw‐r‐‐]  c_3_2.txt 
 

 
Al  igual  que  pasa  con  el  montaje  de  los  sistemas  de  archivos  locales,  cuando  los   sistemas de 
archivos remotos NFS deben montarse  de forma  habitual,  lo  más  cómodo es configurar su montaje en 
el archivo “​/etc/fstab​ ”. Por ejemplo, para el primer caso: 
#cat /etc/fstab 
... 
[Link]:/exportdir/dir_1           /import/serv1/datos_as      nfs  defaults 0 0 
[Link]:/exportdir/dir_3/dir_3_1   /import/serv1/facturas_as/  nfs  defaults 0 0 
... 

 
4.3. Montaje automático: Autofs 
El  montaje  de  varios  sistemas  de  archivo  NFS  al  inicio  de  un  sistema  cliente,  al  leerlos  del 
archivo de configuración ​ /etc/fstab​ , tiene varios inconvenientes. Por una parte, el mantenimiento de 
este  archivo  de  configuración,  al cambiar  los  servidores o  directorios  compartidos  o al añadir  nuevos, 
en  cientos  de  ordenadores  cliente  puede  ser  una  tarea  tediosa.  Cuando  los  directorios  exportados 
mediante  NFS  se  montan  en un cliente  desde  varios  servidores, el  fallo de uno de ellos puede detener 
el montaje del  resto de directorios  o hacer que se demore  demasiado tiempo.  Además, el montaje de 
muchos  directorios  remotos consume bastantes  recursos del cliente  y ralentiza el arranque,  que es  lo 
que ocurre,  por ejemplo, cuando los  usuarios de la organización pueden iniciar sesión en cualquiera de 
home​
los  ordenadores  cliente,  ya  que todos los  directorios  “​ ”  de los  mismos  debe  ser montados, para 
estar disponibles para cada usuario. 
Por  todas  estas razones, una opción  conveniente suele ser el uso del  servicio “​ automount​ ”, que 
monta  los  directorios  automáticamente  cuando  se  intenta   acceder  a  ellos  (montaje bajo demanda) y 
los  desmonta  cuando pasa un tiempo  determinado sin  ser utilizados.  Aunque este  servicio puede ser 
utilizado  de  forma  general  para  el  montaje  de  cualquier  recurso  (dispositivos  de  almacenamiento 
externos,  sistemas  de  archivos  locales,  etc.),  en  esta  sección  nos  vamos  a  centrar  en  sus  uso  más 
frecuente, el montaje de sistemas de archivo en red usando el protocolo NFS.  
autofs  utiliza  el archivo ​
/etc/[Link]​
, conocido como “mapa maestro”, como su fichero 
principal  de  configuración,  si  bien puede ser definido  otro  en su  lugar.  Este  archivo  contiene  una lista 
 
 
Conceptos básicos de administración Linux 
 
de  los  puntos  de  montaje  en  el  cliente  que  deben  ser  controlados  por  ​
autofs  así  como  los 
correspondientes  ficheros  de  configuración  para  cada  punto  de  montaje,  conocidos  como  mapas 
automount​ . El formato de cada línea del mapa maestro es de la siguiente forma: 
punto‐de‐escucha    nombre‐mapa‐automount    [opciones]  
donde: 
● : indica el punto de escucha ​
punto‐de‐escucha​ autofs​
. Es del que tiene que estar pendiente el 
servicio,  para  detectar  si  algún  usuario  intenta  entrar  en  algún  directorio  que  se  encuentre 
dentro  de  él.  No se  trata del directorio en el que  se va a  realizar  el montaje,  sino  su directorio 
padre. 
● nombre‐mapa‐automount​ :  es  el  nombre  del  mapa  que  contiene  la  lista  de   los  puntos  de 
montaje y la localización del recurso que se debe montar en él.  
● opciones​ :  diferentes opciones para  el montaje  (opcional), de forma similar a como ocurría con 
el comando ​ mount​. 
 
Los  mapas  de ​
automount  especificados  en el  archivo  anterior son, de  nuevo, archivos de texto 
que  indican  dónde  se  localizan  los  sistemas  de  archivos  remotos  y  dónde   han  de  montarse.  Dichos 
mapas, pueden ser de dos tipos, directos e indirectos, pero tienen una estructura similar: 
 ​
punto‐de‐montaje   [opciones]   localización  
donde: 
● punto‐de‐montaje​
:  puede  ser  un solo directorio, para un mapa indirecto, o una ruta completa  
para un mapa directo.  
● opciones​ : distintas opciones de montaje (opcional). 
● localización​ :  dirección  remota  del  directorio  exportado  por  NFS  que  se  quiere  montar, 
siguiendo la notación servidor:directorio. 
 
Veamos  un  ejemplo,  suponiendo  las  mismas  carpetas  utilizadas en los  ejemplos anteriores. El 
contenido del mapa maestro podría ser: 
# cat /etc/[Link] 
/import/serv1       /etc/auto.paraelservidor1 

En  este caso indicamos que si algún  usuario entra en un directorio que esté dentro de “/import/serv1” 

(no  en  él,  sino  en  alguno que estuviese dentro) debe  buscar lo que  hacer en  un archivo mapa  que se 
denomina “/etc/auto.paraelservidor1”. Vemos  que el nombre del mapa es libre, así como su ubicación, 
pero se ha ubicado en “/etc” por mantener un orden. El contenido de ese mapa sería: 
# cat /etc/auto.paraelservidor1 
datos_as     [Link]:/exportdir/dir_1 
facturas_as  [Link]:/exportdir/dir_3/dir_3_1 

De esta forma,  si  alguien intenta  acceder a  “datos_as”, lógicamente dentro de “/import/serv1” que es 

donde  ​
automount  está  escuchando,  lo  monta  desde  “[Link]:/exportdir/dir_1”.  Algo  similar 
ocurre con  el otro directorio.  Debemos  darnos cuenta que  en este  caso  ambos directorios  se montan 
desde el mismo servidor NFS, pero nada impide que tuviésemos distintos servidores. 
 
Debemos  tener  cuidado  con  un  aspecto.  En  ocasiones  realizamos  un  “ls”  sobre  uno  de  los 
puntos de montaje automáticos y no obtenemos ningún resultado, por ejemplo: 
 
 
Conceptos básicos de administración Linux 
 

$ls /import/serv1 
 
$ 
$ ls /import/serv1/datos_as/ 
 
$ 

Cuando  se  realiza  el  primer  “ls”,  como  no  se  accede  a  ningún  directorio  contenido  en  el  punto  de 
escucha,  no  se  realiza  el  montaje,  y  no  aparece  ninguna  salida.  En  el  segundo  caso,  tampoco 
obtenemos ninguna  salida, ya que  “ls” no entra realmente en  el directorio, por  lo  que  no se monta. Si 
entramos primero, sí podríamos ver el contenido. Por ejemplo: 
$ cd /import/serv1/datos_as/ 
$ ls 
a_1.txt  dir_1_1 
$ 

 
Otra  forma  de  realizar  lo  mismo  que  en  el  ejemplo  anterior  es  mediante  el  uso  de  un  mapa 
directo, no indirecto. Por ejemplo: 
# cat /etc/[Link] 
/‐       /etc/[Link] 

En  este caso “/‐”  es una notación  especial que  indica que se trata de un mapa directo, el cual quedaría 

de la siguiente forma: 
# cat /etc/[Link] 
/import/serv1/datos_as [Link]:/exportdir/dir_1 
/import/serv1/facturas_as [Link]:/exportdir/dir_3/dir_3_1 

Vemos  que  en este  caso  no  se  atiende a  un  punto  de escucha y  se monta sobre los directorios que se 
encuentran dentro, sino que el  sistema  guarda  todos las posibles rutas absolutas declarada en el mapa 
directo  y  controla  si  alguien  intenta acceder a ellas. Esto genera una  mayor carga  en el  sistema,  pero 
tiene  la ventaja que la estructura siempre está accesible, incluso para el comando “ls”, por ejemplo: 
$ ls datos_as/ 
a_1.txt  dir_1_1 
$ 

 
Otra  de  las  ventajas  de  ​
autofs  es  que  la  información  contenida  en   los  mapas  descritos 
anteriormente,  puede  definirse directamente en  un  servidor  ​ LDAP​ . De esta forma, los administradores 
no  tienen  que  asegurarse  que  los  cambios  se  realicen  en  cada  uno  de  los  clientes,  sólo  realizar  las 
modificaciones en el directorio de información. 
 
4.4. Algunas consideraciones básicas sobre la seguridad en NFS 
  Cualquier  servicio  que  proporcione  acceso  a  archivos  a  través  de  una  red  tiene  múltiples 
problemas  potenciales  de  seguridad.  NFSv4  ha  tenido  en  cuenta  algunos  de  estos  problemas  de 
seguridad, mejorando en muchos aspectos a las versiones anteriores.  
Tradicionalmente,  la  mayor  parte  de  los  servidores  NFS  utilizan  la  autenticación  de  usuarios 
basada  en  AUTH_SYS,  que basa su mecanismo  de autenticación  en los identificadores de  los grupos  y 
los  usuarios Linux,  esto es, de los UIDs y GIDs. En este caso, el cliente envía el UID y GID del usuario que  
 
 
Conceptos básicos de administración Linux 
 

accede al servidor , que los  compara  con su propios valores (que se  encuentran en ​ /etc/passwd​ ) para 

determinar  si  tiene acceso  a  los recursos. Con  este método  tan simple, surgen muchos problemas. Por 
ejemplo, los  administradores  deben asegurarse  que  los archivos de usuarios y grupos (​ /etc/passwd y 
/etc/group​ )  son  ideńticos  en  el  servidor  NFS  y  en  todos  los  clientes  que  accedan  a  él.  Como  se 
desprende  de lo aprendido en  el capítulo  anterior, una  solución  mucho más apropiada es la utilización 
de  un  directorio  que  contenga  los  datos  de  los  usuarios  y   que  sea  consultado  tanto  por  el  servidor 
como  por los  cliente, manteniendo  la consistencia  en los  identificadores de usuarios y grupos entre las 
diferentes  máquinas.  Sin  embargo,  ni  siquiera  esta  centralización  evita los problemas,  ya  que en  una 
red, aunque  fuese local, un usuario podría  conectar un ordenador, por ejemplo un portátil, para el que 
dicho  usuario  tuviese  privilegios  de  administrador.  En  ese  caso,  podría  crear  cualquier  usuario   local 
(que  no  dependa  de  lo  establecido  en  el  LDAP  de  la   organización)  con  el  UID  y  el  GID  deseado, 
accediendo sin problemas a las cuentas del correspondiente usuario en el servidor. Vemos un ejemplo: 
[root@server ~] cat /etc/exports 
/home [Link]/24(rw) 
 
[root@server ~]# cd /home 
[root@server home]# ll 
total 56 
…   
drwxrwx‐‐‐. 2 root    bea      4096 feb  1 20:43 bea 
… 
 
[root@server home]# id bea 
uid=1003(bea) gid=1003(bea) grupos=1003(bea),530(contabilidad) 

/home​
Vemos   que  en  el  servidor  se  ha  exportado  todo   el  directorio  “​ ”  para  que  todos  los  usuarios 
puedan  acceder  a  sus carpetas de una  forma centralizada, dentro de  la red especificada.  También  se 
observa  que  en  ese  directorio  existe  una  carpeta  para  el  directorio  privado  de  la  usuaria  “bea”  y se 
muestra la identidad de dicha usuaria.  
Si alguien  conecta su  ordenador  privado a  la red y conoce el UID y el GID del grupo primario de 
“bea” (por el que está accediendo a su carpeta), podría acceder sin problemas a sus datos. Por ejemplo: 
[root@clientefisgon ~]# groupadd ‐g 1003 grupofisgon 
[root@clientefisgon ~]# useradd ‐u 1003 ‐g 1003 fisgon 
[root@clientefisgon ~]# passwd fisgon 
Nueva contraseña:  
 
[root@clientefisgon ~]# mkdir /import/fisgar 
[root@clientefisgon ~]# mount [Link]:/home/bea /import/fisgar 
[root@clientefisgon ~]# cd /import/fisgar 
‐bash: cd: /import/fisgar: Permiso denegado 
 
[root@clientefisgon ~]# su ‐ fisgon 
[fisgon@clientefisgon ~]$ id 
uid=1003(fisgon) gid=1003(grupofisgon) grupos=1003(grupofisgon) 
 
[fisgon@clientefisgon ~]$ cd /import/fisgar/ 
[fisgon@clientefisgon fisgar]$ ll 
‐rw‐‐‐‐‐‐‐. 1 fisgon grupofisgon 11 mar  3 14:50 [Link] 
[fisgon@clientefisgon fisgar]$ cat [Link]  
mi secreto 
 
 
Conceptos básicos de administración Linux 
 

Podemos ver  que el ​ root del sistema cliente crea un grupo con el mismo GID que el primario de “bea” y 

un  nuevo  usuario,  “fisgon”,  con  el  mismo  UID  y  GID  que  dicha  usuaria.  A  continuación,  crea  un 
directorio  para  montar  la  carpeta  remota,  y  la  monta.  El  ​
root  no  puede  acceder  a esa carpeta, pues 
recordemos  que  por  defecto  las  carpetas  se  exportan  con  la  opción  “root_squash”,  así  que  el  ​ root 
conmutará  al  usuario anónimo en el directorio  montado (más sobre  este aspecto a  continuación). Sin 
embargo,  si  accede como  el usuario  recién creado,  no  tienen ningún problema en entrar en la carpeta 
montada, que  en el servidor pertenece a “bea” y fisgar en su contenido. Podemos observar que cuando 
realiza  el  “ls”,  su  sistema  cambia  el  UID  y  el  GID  usando  los  ficheros  locales  de  configuración 
(​
/etc/passwd  y  / ​etc/group​ ),  por  lo que  el nombre y grupo  que aparecen  son  los que acabamos  de 
crear.  
Uno  de  los mayores problemas es que cuando exportamos las carpetas en el servidor indicamos 
una  o varias direcciones IP  (o  nombres  de máquinas) desde las  que  está  permitido realizar el  montaje 
de  las  mismas.  Es  decir  se  utiliza  la  confianza  en  una  serie  de  máquinas  que  asumimos  son  quienes  
trusted‐host​
dicen  ser (​ ).  Este tipo  de confianza es  obsoleta,  ya  que  existen diferentes formas de burlar 
la  seguridad  basada  en máquinas de  confianza  como mediante  la  alteración de los  sistemas DNS52  o el 
IP spoofing53  (suplantación de IP). 
Para  solventar  los  problemas  anteriores  se  han  implementado  distintas  soluciones,  como  la 
basada en  el mecanismo RPCSEC_GSS54  Kerberos. Kerberos55  es un sistema de autenticación para redes 
de  datos  que  permite a los clientes y servidores autenticarse uno con otro empleando cifrado simétrico 
y  un tercer  elemento confiable (KDC,  ​ key  distribution center o  c​
entro de distribución  de claves​
). El KDC 
es  un servidor  que  actúa como  servidor  de autenticación y como emisor de “tickets” cifrados, que son  
los que usan los usuarios y las máquinas para demostrar la validez de su identidad. 
Para  minimizar los riesgos, se aconseja tomar otras precauciones. Desde el punto de vista de los 
clientes  deberían  montarse  los  directorios  remotos  con  la  opción  “nosuid”  de  forma  que  no  sean 
válidos  los permisos setUID en los  archivos  que contengan las carpetas exportadas. Si el tipo de carpeta 
montada lo permitiese, también es recomendable utilizar la opción de montaje  “noexec”, impidiendo la  
ejecución  de cualquier  archivo ejecutable de dichas carpetas. Desde  el punto de  vista del servidor debe 
mantenerse  siempre  la  opción  de  exportación  por  defecto,  o  indicarla  de  forma  explícita, 
“root_squash”  para  que  el  ​
root  de  la  máquina  cliente no tenga los  mismos  privilegios  en las  carpetas 
montadas a través de NFS.  Si  el caso lo permitiera, por ejemplo cuando exportamos directorios de  solo 
lectura,  deberíamos  activar  también  la  opción  “all_squash”,  degradando  a  todos  los  usuarios  que 
acceden al usuario anónimo. Veamos un ejemplo con el ​ root​
: 
[root@cliente dir_1_1]# echo "hola" > prueba  
[root@cliente dir_1_1]# ls ‐l 
total 8 
‐rw‐rw‐r‐‐. 1 marta     asesores  6 feb 24 23:00 a_1_1.txt 
‐rw‐r‐‐r‐‐. 1 nfsnobody asesores 14 feb 26 14:00 prueba 
 
[root@cliente Libre]# echo "hola" > [Link] 
[root@cliente Libre]# ll 
‐rw‐r‐‐r‐‐. 1 nfsnobody nfsnobody 5 feb 24 22:38 [Link] 
[root@cliente Libre]# id nfsnobody 
uid=65534(nfsnobody) gid=65534(nfsnobody) grupos=65534(nfsnobody) 

52
 "DNS hijacking ‐ Wikipedia, the free encyclopedia." 2011. <​
[Link]
53
 "IP address spoofing ‐ Wikipedia, the free encyclopedia." 2011. <​
[Link]
> 
54
 "Projects: NFS Version 4 Open Source Reference ..." 2002.  <​
[Link] > 
55
 "Kerberos (protocol) ‐ Wikipedia, the free encyclopedia." 2011. <​
[Link]
> 
 
 
Conceptos básicos de administración Linux 
 

En  el primer ejemplo el  ​
root  del cliente crea un  archivo  en  la carpeta “dir_1_1” (utilizada en  ejemplos 
anteriores)  y  vemos  que  el  creador  del  archivo  es  el  usuario  “nfsnobody”.  El  grupo  es  “asesores” 
porque  el directorio tenía el  setGID activo y  es el  grupo  propietario del mismo. En el segundo caso se 
crea  un  archivo en el directorio  remoto “Libre” que  no  tiene activo dicho  permiso especial. Al final  se 
comprueba el UID y GID asignados al usuario anónimo. 
Además,  las  comunicaciones  entre  cliente  y  servidor  son,  por  defecto, no cifradas, por  lo  que 
podría  interceptarse  su  contenido.  Aunque  los  sistemas  NFS  suelen  limitarse  a  intercambio  de 
información  dentro  de  la  ​
intranet  de  la  organización, limitando su acceso desde el  exterior, deberían 
protegerse  las  comunicaciones  utilizando  sistemas  de  cifrado  para  el  tráfico  de  red.  Con mucha más 
razón si se permite el acceso desde el exterior, lo que no suele ser recomendable. 
La  opción  de exportación  de carpetas de sólo lectura  (ro), debe utilizarse siempre que  se desee 
evitar que se modifique el contenido de las mismas, independientemente del usuario que acceda.  
 
4.5. Ejemplo NFS y autofs 
 
Supongamos que tenemos dos servidores que exportan algunas de sus carpetas  a través de 
NFS.  Uno de ellos, con IP [Link], configura su archivo de exportación de la siguiente forma: 
# cat /etc/exports 
/comparto/datosconta     [Link]/24(rw) 
/comparto/datosfiestas   [Link]/24(rw) 
/comparto/datosrrhh      [Link]/24(rw) 
/fotos                   [Link]/24(rw) 

Vemos que las carpetas las ha compartido con todos los ordenadores de la red [Link]/24. 
El otro servidor, con iP [Link], comparte también algunas carpetas: 
# cat /etc/exports 
/export/taller [Link]?(ro) 
/export/info   [Link](rw) 

En  este caso la primera la comparte con todos los ordenadores cuya IP comience por [Link]… y la 
segunda con un ordenador en particular. 
 
autofs​
Una posible configuración de ​  en un cliente podría ser la siguiente:  
# cat /etc/[Link] 
/remoto /etc/[Link] 
/importar       /etc/[Link] 
 
# cat /etc/[Link]  
datostaller [Link]:/export/taller 
*           [Link]:/comparto/& 
 
 
# cat /etc/[Link]  
info     [Link]:/export/info 
*        [Link]:/fotos 

Tenemos  el  mapa  maestro  que  indica  que  si  alguien  intenta  acceder  a  cualquier  carpeta  dentro  de 
“/remoto”  debe  proceder  según   lo  indicado  en  el  mapa  “/etc/[Link]”.  Por  contra,  si  alguien 
 
 
Conceptos básicos de administración Linux 
 
accede  a  alguna  carpeta  dentro  de  “/importar”,  debe  buscar  lo  que  debe  hacer  en 
“/etc/[Link]”.  Para  el  primer  mapa  (/etc/[Link]),  si  el  usuario  accede  a  la  carpeta 
/remoto/datostaller debe montar el directorio “/export/taller” del segundo de los servidores. Si intenta 
entrar  en  cualquier  otra  carpeta  (se  usa  el  comodín  “*”)  debe  montar  las  carpetas  remotas  que  se 
encuentren  en el  primer  servidor,  dentro  de “/comparto” y que se llamen igual que la carpeta a la que 
se  intenta  acceder  (el  comodín  “&”  indica  que  se  sustituye  exactamente  por la misma cadena con la 
que  se  reemplaza  el  “*”).  por  ejemplo  si  se   desea  entrar  en  “/remoto/datosrrhh”  (*=datosrrhh) 
intentará  montar  la  carpeta  remota  del  primer  servidor  que  se encuentra  en “/comparto/datosrrhh” 
(&=datosrrhh). En el segundo caso, cuando un usuario accede a la carpeta “/importar/info” se montará 
la  carpeta  “/export/info”  ubicada  en  el  segundo servidor.  Cuando se  intente  acceder  a cualquier otra 
carpeta,  sea  cual sea el  nombre que elija  el usuario,  montará  la carpeta  del  primer  servidor  localizada 
en “/fotos”. 
 
 
   
 
 
Conceptos básicos de administración Linux 
 

Bibliografía 
 
 

Principles Of Network and System Administration​
Burgess, Mark. ​ . Hoboken, NJ: Wiley, 2004. 

Essential System Administration​
Frisch, AEleen. ​ . Beijing: O'Reilly, 2002. 

UNIX And Linux System Administration Handbook​
Nemeth, Evi. ​ . Upper Saddle River, NJ: Prentice Hall, 

2011. 

Linux System Administration​
Stanfield, Vicki, and Roderick W. Smith. ​ . San Francisco: Sybex, 2002. 

ZYTRAX, ​
Open Source Guide ‐ LDAP for Rocket Scientists ‐ Contents