sistemas operativos mod5

El sistemade ficherosTeodor Jové Lagunas

P05/75097/00808Módulo 5

© FUOC • P05/75097/00808 • Módulo 5 El sistema de ficheros

Índice

Introducción............................................................................................. 5

Objetivos .................................................................................................... 5

1. Definición del sistema de ficheros................................................. 7

2. El concepto de fichero ...................................................................... 8

2.1. Definición de fichero....................................................................... 8

2.2. Las propiedades de los ficheros ....................................................... 8

2.3. Los tipos de ficheros ........................................................................ 8

3. El espacio de nombres ....................................................................... 10

3.1. La función de traducción ................................................................ 10

3.2. La estructura de los espacios de nombres........................................ 11

3.3. Las operaciones sobre el espacio de nombres ................................. 16

4. La protección....................................................................................... 21

4.1. La protección: concepto y objetivos ............................................... 21

4.2. La matriz de accesos ........................................................................ 23

4.3. Las listas de control de accesos........................................................ 24

4.4. Las listas de capabilities (capacidades) ............................................. 25

4.5. Mejoras y modelos combinados...................................................... 25

5. El sistema de ficheros y la protección en UNIX.......................... 27

5.1. El sistema de ficheros en UNIX ....................................................... 27

5.2. El mecanismo de protección de UNIX ............................................ 29

Resumen..................................................................................................... 31

Actividades................................................................................................ 33

Ejercicios de autoevaluación ................................................................ 33

Solucionario.............................................................................................. 34

Glosario ...................................................................................................... 36

Bibliografía............................................................................................... 38

© FUOC • P05/75097/00808 • Módulo 5 5 El sistema de ficheros

El sistema de ficheros

Introducción

Este módulo didáctico se centra en el estudio del sistema de ficheros (SF), y

con este objetivo realizaremos los pasos que exponemos a continuación:

1) En primer lugar estudiaremos el concepto de fichero como dispositivo lógico.

2) En segundo lugar analizaremos el sistema de ficheros en tanto que gestor

de objetos.

3) Y para finalizar, veremos el caso concreto del sistema de ficheros en UNIX.

Los tres aspectos se estudian siempre desde la perspectiva de la asignatura, que

es el punto de vista del usuario del sistema operativo.

Objetivos

Los materiales didácticos de este módulo incluyen las herramientas necesarias

para alcanzar los siguientes objetivos:

1. Conocer las funciones del sistema de ficheros.

2. Conocer el concepto de fichero y saber qué características pueden tener los

ficheros en función de sus propiedades y sus tipologías.

3. Entender la necesidad de utilizar las funciones de traducción para aproxi-

mar los objetos del sistema a las costumbres de los usuarios.

4. Aprender los diferentes tipos de espacios de nombres y sus ventajas e in-

convenientes.

5. Familiarizaros con las operaciones que ofrecen los sistemas operativos para

gestionar los espacios de nombres.

6. Entender los conceptos de seguridad y protección.

7. Ser conscientes de la necesidad de ofrecer herramientas de protección que

permitan llevar a cabo diferentes políticas de protección en función de las

necesidades de los usuarios.

8. Aprender los diferentes esquemas de protección y sus ventajas e inconve-

nientes.


1. Definición del sistema de ficheros

Para ampliar esta información, diremos que el SF se encarga de proporcionar

un espacio de nombres y un control de acceso a todos los dispositivos. Desde

este punto de vista, tanto se puede hablar de ficheros como de dispositivos o,

desde una óptica todavía más general, de objetos gestionados por el sistema y

visibles para los usuarios*.

El sistema de ficheros (SF)* es el encargado de gestionar el conjunto de

ficheros contenidos en un mismo dispositivo de almacenamiento. Esta

gestión se concreta en los tres aspectos fundamentales que indicamos a

continuación:

1) La definición de los dispositivos lógicos que configuran los ficheros.

2) El espacio de nombres, que nos servirá para poder localizar y direc-

cionar los ficheros.

3) El control de las acciones que se pueden efectuar sobre los ficheros.

* Utilizamos la sigla SF como abreviación de sistema de ficheros.

Podéis ver los dispositivos lógicos en el subapartado 3.2. del módulo didáctico “Los dispositivos de entrada/salida”.

* Objetos gestionados por el sistema, como los ficheros,

dispositivos, procesos, espacios lógicos, etc.


2. El concepto de fichero

2.1. Definición de fichero

2.2. Las propiedades de los ficheros

Un fichero posee un conjunto de características o propiedades relacionadas

con los siguientes aspectos:

1) La información relativa al contenido del fichero y a su modificación: tama-

ño, fecha de creación, última fecha de modificación, tipo de información, etc.

2) La ubicación de esta información dentro del dispositivo de almacenamien-

to: este aspecto se refiere a la información necesaria para que el sistema pueda

localizar el fichero dentro del dispositivo de almacenamiento. En la dinámica

general de uso de los ficheros, los usuarios del sistema no necesitan conocer esta

información, pero les puede resultar útil conocerla dado que en algunas situa-

ciones se puede destruir una parte de la misma, tanto si es porque se ha hecho

un uso incorrecto de ésta, como por un mal funcionamiento del sistema*.

3) La accesibilidad del fichero: este aspecto hace referencia a la información re-

lacionada con quién es el usuario propietario del fichero y con las operaciones

que los diferentes usuarios pueden realizar, tales como escribir, leer, ejecutar, etc.

Todas estas informaciones están relacionadas con el concepto de protección.

2.3. Los tipos de ficheros

El SO puede reconocer diferentes tipos de ficheros en función de la estruc-

tura de la información que contienen, su finalidad, las operaciones de ac-

ceso que permiten y otros aspectos más. En este módulo didáctico nos

vamos a centrar únicamente en estas tres primeras características, que es-

tán muy interrelacionadas.

Un fichero es un dispositivo lógico formado por una agrupación lógica

de información almacenada en un dispositivo físico, por ejemplo un

disco, una cinta o en la memoria, que se puede manipular como un to-

do. La información que incluye tiene en común un conjunto de propie-

dades que la caracterizan.

* El mal funcionamiento del sistema se puede deber al hardware

o al software.

Podéis ver el concepto de protección en el apartado 4de este módulo didáctico.


Así pues, en un SO podemos encontrar ficheros que contienen caracteres o

información en formato binario, gráfico, etc. También podemos encontrar

ficheros ejecutables, librerías, fuentes, directorios, documentos, hojas de

cálculo, bases de datos, etc. La información contenida en los ficheros siem-

pre tiene una estructura y una finalidad, dos características que condicio-

nan la forma de acceder a los mismos y el tipo de funciones que pueden

llevar a cabo. En general, sobre los ficheros se puede realizar el mismo con-

junto de operaciones que se puede llevar a cabo sobre cualquier dispositivo.

A pesar de esto, en función de la estructura y la finalidad de esta informa-

ción, el sistema operativo tiene la posibilidad de ampliar o restringir el con-

junto de operaciones posibles.

Un caso de ampliación de operaciones es, por ejemplo, el que se produce con

los ficheros ejecutables. Un fichero ejecutable, tal como hemos visto, contie-

ne un tipo de información con una estructura muy determinada que le permi-

te al SO cargarla en la memoria como código de un proceso. Así pues, el

sistema permite efectuar una acción especial sobre estos ficheros: la ejecución.

Esta acción, tal como la acabamos de definir, carece de sentido en ficheros que

no sean ejecutables; asimismo, algunos sistemas pueden redefinir la acción de

ejecutar si asocian a la estructura de un fichero una aplicación que pueda in-

terpretarla y/o manipularla.

Ejemplos de redefinición de la acción de ejecutar

A continuación presentamos un par de ejemplos en los que podemos ver la redefiniciónde la acción de ejecutar:

a) Un ejemplo es el caso del sistema operativo Windows NT, que, al ejecutar un ficherográfico, inicia la aplicación asociada con la capacidad de entender la información quecontiene el fichero.

b) Otro ejemplo es el caso de los ficheros que incluyen shell-scripts. En el sistema UNIX,cuando se lleva a cabo la acción de ejecutar un shell-script, el sistema lo detecta y ejecutael shell que tiene la capacidad de interpretar la información del fichero que configura lasórdenes.

Otro caso muy diferente son los ficheros directorios, que tienen una estruc-

tura que consiste en una lista de parejas de nombres y números y cuya finali-

dad es dar nombre a los ficheros y permitir su localización. En este caso, el

sistema sólo nos permite acceder a los directorios mediante un conjunto muy

concreto de operaciones para proteger la gestión que realiza sobre los ficheros

en general.

Podéis ver las operaciones que pueden tener lugar sobre los dispositivos en el subapartado 4.2. del módulo didáctico “Los dispositivos de entrada/salida”.

Podéis ver el shell en el subapartado 5.3. del módulo didáctico “Los dispositivos de entrada/salida”.

Podéis ver los ficheros directoriosen el apartado 3 de este módulo didáctico.


3. El espacio de nombres

Tal y como hemos visto en la introducción, una de las funciones propias del

SF es proporcionar un espacio de nombres que permita la localización y ma-

nipulación de los ficheros. Esta visión es extensible a todos los objetos que ges-

tiona el sistema y que los usuarios tienen que identificar en algún momento.

Así pues, a partir de ahora en este apartado utilizaremos de manera indistinta

los términos fichero, dispositivo u objeto.

3.1. La función de traducción

En un sistema se gestionan multitud de objetos*. Para poder gestionarlos to-

dos es necesario cumplir los siguientes requisitos:

• Conocer los objetos que hay y sus características.

• Poder acceder a éstos para interactuar.

• Poder crearlos y destruirlos.

Para efectuar estas operaciones, es necesario que los objetos tengan nombre,

con el fin de que el sistema y los usuarios los puedan identificar. Dentro del

sistema se identifica cada uno de los objetos mediante lo que podríamos de-

nominar nombres internos, que consisten en direcciones de memoria, índi-

ces de tablas o números en general.

Un caso especial son los dispositivos y los ficheros con los que los usuarios te-

nemos que interactuar directamente. Entonces el sistema tiene que proporcio-

nar nombres cercanos a nuestros hábitos. Nos resultará mucho más fácil

recordar que el dispositivo con el nombre impresora es la impresora que recor-

dar un número que suele tener varias cifras.

El SF se encarga de proporcionar y gestionar un espacio de nombres que nos

permita alcanzar este objetivo.

Una de las funciones del SF es facilitar una función de traducción entre

unos nombres a los que estamos acostumbrados los humanos y los nom-

bres internos del sistema o, lo que es lo mismo, los objetos tal y como los

conoce el sistema.

F: nombre objeto.

El conjunto de todos los nombres posibles configura lo que conocemos

por espacio de nombres. La función de traducción tiene que ser unívo-

ca: un nombre sólo puede hacer referencia a un objeto y sólo a uno.

Recordad

En el caso del sistema operativo UNIX, el nombre interno está compuesto por la unión de un major y un minor.

* Algunos de los objetos que gestionan los sistemas son

los ficheros, los dispositivos, los procesos y los espacios lógicos.


El SO implementa la función de traducción de los nombres mediante estruc-

turas de datos que denominamos directorios, los cuales, a su vez, son imple-

mentados mediante ficheros en los que el sistema almacena la estructura de

datos que da lugar a la función de traducción. Esta estructura de datos consiste

en una tabla que relaciona los nombres que contiene el directorio con los

nombres internos del SO (observad la figura 1). Así, un directorio se puede ver

como una agrupación de nombres de objetos. Teniendo en cuenta que los SF

se pueden contener en dispositivos extraíbles, cada SF tiene que contener el

directorio que configura su espacio de nombres.

Un sistema operativo puede ofrecer una visión de un único espacio de nom-

bres para todos los objetos y SF, o de un espacio de nombres separado e inde-

pendiente de los otros para cada tipo de objeto o SF.

Espacio de nombres en UNIX y en DOS

En UNIX, los ficheros y los dispositivos se denominan mediante un mismo espacio que gestio-

na el SF. El caso del DOS es diferente, ya que dispositivos y ficheros poseen espacios separados:

• Los dispositivos tienen unos nombres prefijados, como A:, B:, etc. para los discos, y

CON:, LPT1:, etc. para el resto de los dispositivos.

• En cambio, los ficheros se nombran con el nombre del disco que los contiene, seguido

del nombre del fichero, por ejemplo A:\AUTOEXEC.BAT.

3.2. La estructura de los espacios de nombres

Este subapartado se centra en los diferentes tipos de espacios de nombres que

puede tener el SF. Podemos clasificar los espacios de nombres en espacios linea-

Figura 1


les y espacios jerárquicos, que, al mismo tiempo, pueden estar distribuidos en

forma de árbol o en forma de grafo dirigido.

1) El espacio lineal

Los espacios lineales son útiles para referenciar objetos internos del sistema o

para espacios con un número de objetos pequeño.

De este modo, en un sistema monousuario en el que todos los ficheros tienen

que ser visibles para un único usuario, pueden ser un buen medio de organi-

zación. Ahora bien, cuando el número de ficheros crece, los nombres que uti-

lizamos irán incrementando su complejidad para no perder la capacidad de

distinguir los diferentes ficheros. Así pues, cada vez es más difícil recordar qué

nombre tenía un fichero concreto; teniendo en cuenta esta situación, el obje-

tivo de proporcionar unos nombres próximos a las costumbres y hábitos de los

humanos resulta imposible.

En resumen, por lo que respecta a los espacios lineales, podemos decir que

son:

• Adecuados para espacios con pocos objetos, ya que se trata de una estruc-

tura que permite tener una buena visión de conjunto y conseguir una lo-

calización rápida de cualquier objeto.

• Inadecuados cuando el número de objetos empieza a ser elevado, ya que

el significado que para los humanos pueden tener los nombres puede llegar

a quedar desvirtuado.

El espacio lineal es el espacio de nombres más sencillo, ya que tiene una

sola dimensión en la que todos los nombres se encuentran en el mismo

nivel, contenidos en un único directorio. Dicho de otra forma, no se pu-

eden hacer clasificaciones de los diferentes objetos

Espacios lineales en UNIXy en DOS

En DOS, por ejemplo, los discos tienen un espacio lineal (a:, b:, c: ...). En UNIX los procesos también tienen nombres dentro de un espacio lineal; este nombre es el PID (Process Identification Digit), que es un entero. En este caso, el nombre de un proceso es un dato interno que será utilizado por los usuarios en contadas ocasiones.

Figura 2


2) Espacio jerárquico

Con esta idea podemos organizar los espacios jerárquicos de las dos formas

que presentamos a continuación:

a) Estructura de árbol. Es la estructura jerárquica más sencilla en la que po-

demos organizar los ficheros. Un espacio jerárquico en forma de árbol se con-

figura a partir de una jerarquía de directorios con un directorio raíz del cual

cuelgan otros directorios y/o ficheros, que configurarán las hojas del árbol.

Como usuarios nos gustaría agrupar los ficheros por tipos, trabajos o

según cualquier criterio que nos ayude a llevar a cabo la organización

del SF, puesto que de esta manera sería mucho más fácil localizarlos.

La manera de conseguir este objetivo es dotar a los nombres del sis-

tema de ficheros de una estructura jerárquica. Para conseguir un es-

pacio jerárquico tratamos los directorios como objetos con un

nombre y, así, pueden formar parte de los objetos que agrupan otros

directorios.

Figura 3


Denominamos nombre absoluto el nombre formado por la ruta que va desde

la raíz, pasando por los diferentes subdirectorios, hasta llegar al fichero. Así

pues, el nombre absoluto está compuesto por una secuencia de cadenas de ca-

racteres, o componentes del nombre, contenidas en los subdirectorios que

configuran la ruta de acceso al fichero. Los componentes se separan por un ca-

rácter delimitador*.

Para facilitar la manipulación de los ficheros en las estructuras jerárquicas se

define:

• El directorio inicial, que es el directorio desde donde un usuario puede

crear su estructura de directorios y donde colocará los ficheros que cree.

• El directorio de trabajo, que es el directorio donde se encuentran los fi-

cheros con los que se está trabajando en un instante concreto. Cuando un

usuario empieza la sesión de trabajo, el directorio de trabajo es el directorio

inicial.

En relación con el concepto de directorio de trabajo tenemos el de nombres

relativos, que son aquellos nombres que están formados por el recorrido que

va desde el directorio de trabajo hasta el fichero. Varios ficheros pueden tener

el mismo nombre relativo, siempre que éste se obtenga a partir de diferentes

directorios de trabajo*.

Como ya hemos indicado, una estructura en árbol soluciona los problemas or-

ganizativos que plantea la estructura lineal. A pesar de todo, tiene estos dos

inconvenientes:

• No permite compartir de una manera sencilla ficheros entre diferentes

usuarios.

• No permite moverse por el árbol de directorios en sentido ascendente,

cambiando el directorio de trabajo.

b) Estructura de grafo dirigido. Para solucionar los problemas que plantea la

estructura en árbol, definimos el espacio de nombres con una estructura de

grafo dirigido como la que se representa en la figura 4.

Con la estructura de la figura 4, un fichero se puede direccionar al mismo

tiempo con los nombres absolutos /hombre/juan/ejercicio1.txt y

/hombre/maria/ejercicioA.txt. De esta manera, puede ser compar-

tido fácilmente por más de un usuario.

En una estructura en grafo dirigido, se puede acceder a un mismo objeto me-

diante más de un nombre y, por lo tanto, también se puede acceder desde di-

ferentes directorios de trabajo.

* En UNIX el carácter delimitador es /.

* Con lo cual los nombres absolutos no son iguales.


Con esta estructura el sistema genera automáticamente nombres adicionales

para cada directorio del SF. Por ejemplo, en UNIX y en DOS, en cada directorio

figuran dos nombres especiales: el “.” y el “..”.

• El nombre “.” hace referencia al directorio que lo contiene; se utiliza para

referenciar el directorio de trabajo sin necesidad de conocer su nombre ab-

soluto.

• El nombre “..” es el nombre del padre del directorio que lo contiene; se uti-

liza para referenciar, mediante nombres relativos, objetos que tienen como

parte de su nombre subdirectorios que se encuentran por encima del direc-

torio de trabajo.

En general, los directorios “.” y “..” permiten referenciar objetos mediante

nombres relativos sin que sea necesario conocer el actual directorio de trabajo.

El principal inconveniente de los espacios con estructura de grafo dirigido es,

como veremos a continuación, su gestión.

Ejemplo de dirección

En el caso de la figura 4, si el directorio de trabajo es /hombre/maria, se puede acceder al fichero con nombre absoluto /hombre/juan/ejercicio2.txt con el nombre relativo .. /juan/ejercicio2.txt.

Figura 4


3.3. Las operaciones sobre el espacio de nombres

Una vez se ha visto qué es un espacio de nombres, pasamos a las operaciones

que podemos llevar a cabo. El sistema ofrece tres tipos de operaciones: operacio-

nes para manipular el SF como un todo, operaciones para gestionar los conteni-

dos de los directorios y, por último, operaciones para manipular el directorio de

trabajo. Acto seguido trataremos cada uno de estos tipos de operaciones.

1) Operaciones de manipulación del SF

a) Operación crear_SF. Como ya hemos visto, un SF se incluye dentro de un

dispositivo de almacenamiento y organiza la información de este dispositivo

en ficheros. Para que esto sea posible, es necesario dotar a dispositivo de un

conjunto de estructuras de datos que permitan definir los ficheros, localizarlos

mediante un espacio de nombres, crear otros nuevos, gestionar el espacio li-

bre, etc. La operación crear_SF es la encargada de generar todas estas estructu-

ras que se guardarán dentro del mismo dispositivo de almacenamiento. Este

hecho permitirá, en caso de que se utilice un dispositivo extraíble, transportar

el SF de un sistema a otro sin que se produzca pérdida de información.

b) Operación montar_SF. Algunos SO tienen que ser informados antes de ac-

ceder a un nuevo SF, tanto si es porque se acaba de introducir un volumen

nuevo que contiene un SF en un dispositivo extraíble como si es porque se ha

creado un SF nuevo en un dispositivo ya existente, etc. El sistema necesita ini-

cializar una serie de estructuras de datos internos para optimizar los accesos al

SF, para reconocer de qué tipo de SF se trata, para restringir el tipo de acceso*

sobre el SF o para dar, como en UNIX, una nueva visión de un único espacio

de nombres, etc. La operación montar_SF es la encargada de llevar a cabo todas

estas acciones.

c) Operación desmontar_SF. De manera análoga al caso anterior, antes de re-

tirar el volumen de un dispositivo extraíble al que se está accediendo como SF,

hay que efectuar la operación desmontar_SF para que se liberen las estructuras

de datos que se han reservado en la operación de montaje.

d) Operación verificar_SF. Finalmente, el sistema nos proporciona herra-

mientas para verificar las estructuras de datos que configuran un SF y que es-

tán contenidas en el dispositivo mediante la operación verificar_SF. Por norma

Hemos visto los dispositivos extraíbles en el subapartado 3.1.de este módulo didáctico.

* Los tipos de acceso permitidos son de lectura y de escritura.


general, estas herramientas no forman parte del núcleo del SO, sino que son

aplicaciones y utilidades que se ejecutan sobre el SO.

2) Operaciones de manipulación de directorios

Las operaciones de manipulación de directorios nos permiten acceder a la ta-

bla que implementa la función de traducción, que se encuentra almacenada

dentro del fichero que configura el directorio.

a) Operación localizar_objeto. Consiste en, dado un nombre (relativo o ab-

soluto), localizar el objeto al que hace referencia. En los sistemas no existe nin-

guna llamada que efectúe exclusivamente esta operación. La localización de

un objeto mediante su nombre es un procedimiento que forma parte de mul-

titud de llamadas. En general, cualquier llamada al sistema que haga referencia

a uno de los objetos contenidos en el SF tiene que utilizar este procedimiento.

b) Operación modificar_nombre. Consiste en localizar el directorio que con-

tiene el nombre que hay que modificar y, tras haber verificado que el nombre

es único, cambiarlo por el nuevo.

c) Operación crear_nombre. Es la encargada de crear un nombre para un ob-

jeto concreto. Esta acción se puede separar en diferentes operaciones en fun-

ción de si el objeto ya existe y, por lo tanto, sólo se pretende crear un nombre

nuevo, o si el objeto no existe y, en consecuencia, la creación del nombre se

lleva a cabo en el mismo instante en que se crea el objeto:

• La creación de nombres sobre objetos ya existentes se puede ver como el es-

tablecimiento de un enlace entre el nombre y el objeto al que hace referencia.

Así pues, las operaciones de manipulación del SF pueden tener la si-

guiente forma:

• Estado = crear_SF(nombre, tipo, etc.).

• Estado = montar_SF(dispositivo, tipo, modoL/E, etc.).

• Estado = desmontar_SF(dispositivo).

• Verificar_SF no es una llamada al sistema, sino una utilidad.


Desde esta óptica, la creación de un nombre nuevo consiste simplemente en

añadir una línea de información en la tabla del directorio. Sin embargo, an-

tes es necesario localizar el objeto al que se quiere dotar de nombre, y hay

que comprobar que dicho nombre sea único. Este tipo de nombre se cono-

ce como enlace físico, en contraposición con los denominados enlaces sim-

bólicos.

Un enlace simbólico es un enlace que no relaciona de manera directa un

nombre con un objeto, sino que lo hace indirectamente mediante un enlace

a otro fichero que contiene el nombre del objeto, como se ve en la figura 5.

Este tipo de nombres se utiliza fundamentalmente para dar un nombre a un

objeto que se encuentra en un dispositivo de almacenamiento diferente de

donde está el directorio que contiene el enlace simbólico. La existencia de

los enlaces simbólicos hace que la operación localizar_objeto se vea obligada

a saber de qué tipo es cada enlace, y a actuar en consecuencia.

• La creación de nombres junto con los objetos a los que hacen referen-

cia, que añade la problemática propia de la creación de los objetos en con-

creto. Nosotros nos centraremos en la operación de crear un subdirectorio.

En este caso, el sistema tiene que proporcionar una operación que, dado el

nombre del directorio que se quiere crear y el del directorio desde donde

tiene que colgar, cree el fichero que debe contener el directorio nuevo, su

tabla de traducción y los enlaces “.” y “. .”.

Figura 5


d) Operación destruir_nombre. Consiste en localizar el directorio que contie-

ne el último componente del nombre que se quiere destruir y borrar la entrada

de la tabla de traducción que lo contiene. Si el fichero al que hacía referencia

este nombre ya no tiene ningún otro nombre, el SO lo destruirá y liberará los

recursos que ocupa. Al comprobar si el fichero tiene otro nombre, nos encon-

traremos con las dos situaciones siguientes:

• El hecho de destacar si un fichero no tiene ningún otro nombre es sencillo

si nos referimos a los enlaces físicos, ya que éstos suelen estar contabiliza-

dos en las características del fichero e incluidos en el dispositivo de alma-

cenamiento que contiene el SF.

• Por el contrario, la detección de enlaces simbólicos no es trivial, teniendo

en cuenta que los enlaces simbólicos del fichero que se quiere destruir no

tienen por qué hallarse en el mismo dispositivo, y éste no tiene que encon-

trarse necesariamente activo en el sistema. Por lo tanto, es imposible detec-

tarlos, de modo que el sistema ignora su existencia durante la operación de

destruir.

Como resultado de esto, puede ser que aparezcan enlaces simbólicos que no

señalen ningún fichero o, todavía peor, que apunten a un fichero diferente del

que querían apuntar pero que ha reutilizado el nombre del fichero destruido.

Para solucionarlo el sistema detecta los enlaces simbólicos que ya no apuntan

a ningún fichero mediante la operación localizar_objeto.

e) Operación ver_nombres. Permite consultar el contenido de un directorio,

así como ver el tipo y las propiedades de los objetos a los que hace referencia.

Así pues, las operaciones de manipulación de directorios pueden quedar

de la siguiente forma:

• Localizar_objeto, que forma parte del resto de las operaciones.

• Estado = modificar_nombre(nombre_nuevo, nombre_viejo).

• Estado = crear_nombre(directorio, nombre_nuevo, simbólico_físico, objeto).

• Estado = destruir_nombre(nombre).

• Valores = ver_nombres(directorio).


3) Operaciones de manipulación del directorio de trabajo

Existen dos operaciones de manipulación del directorio de trabajo: cambio_de_

_directorio y dir_actual, que simplemente nos indican en qué directorio esta-

mos trabajando en un instante determinado y cómo podemos cambiar el di-

rectorio de trabajo.

Los parámetros que podrían tener las operaciones de manipulación del

directorio de trabajo son los siguientes:

• Estado = cambio_de_directorio(nuevo_directorio).

• Dir_actual = directorio_actual( ).


4. La protección

Como en el apartado anterior, enfocaremos el tema de la protección desde el

punto de vista del acceso a los ficheros, aunque los conceptos y las técnicas

que estudiaremos se pueden hacer extensibles, con total facilidad, al caso ge-

neral del conjunto de los objetos que gestiona el SO.

Como ya sabemos, un SO gestiona un conjunto de recursos y objetos sobre los

cuales se pueden efectuar acciones. Es responsabilidad del sistema operativo

garantizar su buen funcionamiento e impedir que la dinámica de unos usua-

rios se vea afectada por las acciones de otros o por las acciones de agentes ex-

ternos al sistema computador.

El concepto de protección hace referencia al primero de estos aspectos, y es el

mecanismo que proporciona el sistema para autorizar o denegar los accesos

que en un instante concreto solicitan los usuarios.

El concepto de seguridad del sistema, en cambio, se centra básicamente en el

segundo aspecto, e incluye temas como la identificación y autoidentificación

de los usuarios, así como cuestiones administrativas y organizativas relaciona-

das con la gestión de un sistema informático.

Como es evidente, seguridad y protección son dos conceptos muy relacionados.

A pesar de esto, en este módulo nos centraremos en el mecanismo de protec-

ción, y supondremos que los usuarios han sido debidamente identificados y

que, por lo tanto, en realidad son quienes dicen que son.

4.1. La protección: concepto y objetivos

Hay dos casos en los que no es necesaria la existencia de un mecanismo de pro-

tección:

a) El estudio de la protección tiene sentido desde el momento en que hay más

de un usuario en el sistema, y éstos pueden decidir cómo y con quién compar-

ten los ficheros que crean. En consecuencia, la protección carece de sentido en

un sistema en el que tenemos un solo usuario. En tal caso podemos admitir

El concepto de protección se refiere al control que lleva a cabo el SO so-

bre las diferentes formas con que cuentan los usuarios para acceder a los

objetos del sistema.


que no es necesario ningún tipo de control sobre los accesos que se llevan a

cabo a los ficheros, puesto que la totalidad de los ficheros pertenece al mismo

usuario, y él controla el uso que hace de los mismos.

b) Un caso similar es el de un sistema multiusuario en el que se permite que to-

dos los usuarios accedan a todos los ficheros. No existe el concepto de propiedad

de un fichero y, en consecuencia, no hay restricciones para acceder al mismo.

Así, en esta situación tampoco sería necesario un sistema de protección.

Si se da el caso contrario, cuando cada usuario sólo puede acceder a los ficheros

que ha creado, sí se necesita un mecanismo de protección que controle la identi-

dad de los procesos que tratan de acceder a los ficheros y a su propiedad. Este me-

canismo constituye un caso restrictivo con respecto al caso general en el que se

permite a los usuarios compartir ficheros mediante un acceso controlado.

Nos centraremos en este último supuesto de carácter más general para analizar

los diferentes mecanismos de protección.

Como hemos visto, se pueden dar diferentes necesidades a la hora de proteger

un objeto, y éstas dependen del objeto en concreto, de los usuarios que pue-

den acceder al mismo y del tipo de acciones que se pueden efectuar. Por este

motivo, el sistema tiene que proporcionar una herramienta lo bastante flexi-

ble como para que los usuarios puedan implementar diferentes políticas de

protección en función de sus necesidades.

Antes de ver los mecanismos de protección en los apartados siguientes, tene-

mos que analizar los diferentes elementos que intervienen en la protección,

y que son éstos:

1) Los objetos: son todos aquellos elementos que gestiona el SO sobre los cua-

les se pueden efectuar diferentes acciones de las cuales quizá tendrán que ser

protegidos. Por ejemplo, son objetos los ficheros, los dispositivos, los directo-

rios, los procesos, etc.

2) Los dominios: son los diferentes agentes activos del sistema que pueden

actuar sobre un objeto. Así, por ejemplo, son dominios los procesos que per-

tenecen a un usuario o a un grupo predefinido de usuarios, etc.

3) Los derechos: son acciones sobre un objeto permitidas por parte de un do-

minio. Por ejemplo, son derechos leer, escribir, ejecutar, crear, destruir, etc.

Los mecanismos de protección que nos disponemos a analizar a continuación

presentan diferentes formas de relacionar los derechos que cada dominio tiene

sobre cada objeto.


4.2. La matriz de accesos

En esta matriz, el dominio Juan tiene derechos de lectura y escritura sobre el

objeto ejercicio1.txt, pero en cambio, sólo tiene derechos de lectura sobre

el objeto ejercicioB.txt y de ejecución sobre edit. El hecho de tener de-

rechos de escritura sobre el directorio Juan le permitirá crear nuevos ficheros

en este directorio. El derecho de propietario que tiene sobre el fichero

ejercicio1.txt le permite la modificación de cualquier derecho que se en-

cuentre en la columna asociada a este fichero. Por ejemplo, puede facilitar el

derecho de escritura al dominio María sobre este fichero.

En la tabla observamos que los dominios aparecen como objetos debido a que

un dominio también es un objeto sobre el cual se pueden llevar a cabo accio-

nes y, por tanto, tienen que ser sometidas al mecanismo de control.

Por ejemplo, el dominio Profesores de la matriz anterior tiene derecho de

cambio sobre el dominio Estudiantes, lo cual significará que un proceso que

La matriz de accesos está formada por tantas filas como dominios (Di)

hay, y por tantas columnas como objetos (Oj). Cada celda Dij de la ma-

triz contiene los derechos de acceso del dominio Di sobre el objeto Oj.

Matriz de accesos

Dominios Objetos

ejer

cici

oA.t

xt

ejer

cici

oB

.txt

ejer

cici

o1.t

xt

ejer

cici

o2.t

xt

edit

Dir

ecto

rio

Juan

Dom

inio

Juan

Dom

inio

Mar

ía

Dom

inio

estu

dia

nte

s

Dom

inio

pro

feso

res

Dom

inio

adm

inis

trad

or

Juan Leer Leer

LeerEscribirPropie-tario


Ejecutar


Propie-tario


María



Leer Leer Ejecutar Leer Propie-tario

Estudiantes Leer Leer Leer Leer Ejecutar Leer Propie-tario

Profesores Ejecutar Control Propie-tario

Administra-dor

LeerEscribirEjecutarPropietario

Control ControlControl Propie-tario


pertenezca al dominio Profesores se puede transformar, a partir de un ins-

tante concreto, en un proceso del dominio Estudiantes.

Otro ejemplo es el derecho de control del dominio Administrador, que per-

mite modificar cualquier celda del dominio sobre el cual actúa; así, por ejem-

plo, el administrador tiene la posibilidad de modificar cualquier derecho de

los dominios Administrador, Juan y María.

La matriz de accesos es una buena forma de contemplar las relaciones que se

establecen entre los diferentes elementos que intervienen en el mecanismo de

protección. No obstante, no es un buen instrumento de trabajo por los si-

guientes motivos:

• Su volumen crece rápidamente a medida que aumenta el número de usua-

rios y de ficheros del sistema.

• El número de objetos sobre los cuales un dominio tiene derechos es pequeño

en relación con el número total de objetos del sistema, y, por tanto, la matriz

es una estructura muy grande con la mayor parte de las celdas vacías.

Para solucionar estos problemas se han propuesto dos métodos que consisten

en dividir la matriz por columnas o por filas. En los próximos subapartados

analizaremos los efectos que tienen estas soluciones.

4.3. Las listas de control de accesos

Con este esquema, debido a que la LCA se encuentra asociada a los objetos y

no a los procesos, cada vez que un proceso quiere llevar a cabo un acceso a un

objeto hay que verificar si tiene derecho recurrente en la LCA. Y esto quiere

decir que en una sesión de trabajo con un fichero se verifican los derechos en

cada operación de lectura o escritura que se quiere realizar, hecho que repre-

sentará un volumen de sobrecarga importante para el sistema.

Una ventaja de este esquema es que todos los derechos que poseen los domi-

nios sobre un objeto se encuentran en un mismo lugar, la LCA. Esta circuns-

tancia hace que la asignación y la revocación de derechos por parte del

propietario del objeto se puedan efectuar con total sencillez.

Una lista de control de accesos (LCA) es una lista de parejas (derechos,

dominio) asociada a un objeto y que se obtiene como resultado de divi-

dir la matriz de accesos en columnas y eliminar todas las celdas vacías.

De esta manera el sistema se ahorra espacio y obtiene una estructura

más dinámica.


4.4. Las listas de capabilities (capacidades)

Las listas de capabilites son estructuras de datos asociadas a procesos. El sistema

las puede gestionar de las dos maneras siguientes:

a) Protegiéndolas en su espacio y proporcionando llamadas para que los pro-

cesos las puedan utilizar.

b) Dejando que los procesos las gestionen directamente. En este caso, las ca-

pabilities se protegen mediante técnicas de cifrado que evitan que se modifi-

quen los derechos que contienen.

En cualquiera de los dos casos, cuando un proceso accede a un objeto, tiene

que presentarle al sistema la capability que le da derecho a llevarlo a cabo. El

sistema verifica su validez y efectúa el acceso (el acceso a este mecanismo es

más ágil que a las LCA).

En cambio, la modificación de los derechos que tienen los dominios sobre un

objeto por parte del propietario no es trivial, ya que los derechos se encuen-

tran repartidos por todos los procesos del sistema y, en consecuencia, en caso

de querer revocar un derecho de todos los dominios, hay que hacer un reco-

rrido por todos y eliminar las capabilities asociadas.

4.5. Mejoras y modelos combinados

Como acabamos de ver, los modelos de LCA y de capabilities presentan algu-

nos inconvenientes. Para solucionarlos, la mayoría de los sistemas utilizan

una combinación de los dos modelos que permite disfrutar de las ventajas de

cada esquema.

Las LCA se utilizan como mecanismo básico, y se suelen presentar realizando

una reducción de todos los dominios posibles a unos cuantos. Esto se consigue

agrupando los dominios, como por ejemplo en UNIX, donde hay tres grupos: el

propietario (por ejemplo Juan), todos los dominios asociados al grupo de traba-

jo del propietario (por ejemplo Alumnos) y el resto de los dominios del sistema.

Los primeros accesos a cada objeto se verifican mediante las LCA. Este primer

acceso se puede concretar, por ejemplo, en la operación abrir que se efectúa al

iniciar una sesión de trabajo con un fichero o un dispositivo. Tras haber veri-

Una lista de capabilities es una lista de parejas (objeto, derechos) asociada

a un dominio, cada una de las cuales se denomina capability. Las listas

de capabilities resultan de dividir la matriz en filas y eliminar, igual que

en las listas de control de acceso, todas las celdas vacías.

Podéis ver la operación abrir en el subapartado 4.2. del módulo didáctico “Dispositivosde entrada/salida”.


ficado el derecho, el sistema genera una capability que se utilizará durante la

sesión de trabajo. Por norma general, esta capability se asocia al dispositivo vir-

tual que se genera durante la operación abrir y, una vez ha finalizado la sesión

de trabajo, la capability se destruye con la operación cerrar. De esta manera, los

accesos de lectura y escritura que se llevan a cabo durante la sesión de trabajo

no necesitan acceder al LCA, ya que están autorizados por el simple hecho de

utilizar el dispositivo virtual asociado.

Otra mejora, en este caso en el mecanismo de capabilities, consiste en dotarlo

de una herramienta de revocación eficiente. Una posibilidad es el llamado me-

canismo de llave y cerrojo. En este esquema cada capability tiene asociado un

número denominado llave y los objetos tienen asociada una colección de nú-

meros denominados cerrojos. Para que una capability sea correcta, la llave tie-

ne que coincidir con alguno de los cerrojos que posee el objeto. Para revocar

un conjunto de derechos, lo único que debe hacer el propietario del objeto es

eliminar uno o más cerrojos. Como es evidente, este mecanismo no tiene la

flexibilidad de las LCA, pero soluciona parcialmente el problema de tener que

recorrer todos los dominios para eliminar las capabilities asociadas.

Podéis ver los dispositivos virtuales en el subapartado 4.1. del módulo didáctico “Los dispositivosde entrada/salida”.


5. El sistema de ficheros y la protección en UNIX

5.1. El sistema de ficheros en UNIX

En UNIX nos encontramos con los tres grupos de ficheros siguientes:

1) Los ficheros ordinarios, que son los ficheros tal y como los hemos estu-

diado en este módulo.

2) Los ficheros directorio, que son los que configuran la función de traduc-

ción del espacio de nombres.

3) Los ficheros especiales o dispositivos, que como su nombre indica, son

los dispositivos del sistema.

El sistema operativo UNIX reconoce un solo tipo de fichero ordinario que per-

cibe todos los ficheros como una secuencia de bytes, a los cuales se accede me-

diante operaciones específicas. Esta regla sólo tiene una excepción: los ficheros

ejecutables. Un fichero ejecutable tiene una estructura muy concreta que el SO

reconoce y utiliza en el momento de cargar un programa en la memoria. UNIX

utiliza los primeros bytes de esta estructura del fichero para dejar en él una marca

que distinga un fichero normal de uno ejecutable:

a) El hecho de que no se encuentre la marca garantiza que el fichero no es un

ejecutable.

b) Sin embargo, la existencia de la marca no garantiza que el fichero sea eje-

cutable, ya que puede haber ficheros binarios que por azar cuenten con la mis-

ma combinación de bytes al principio.

El sistema de ficheros de UNIX presenta una estructura de grafo dirigido orga-

nizada en directorios, tal y como hemos visto. Cada fichero puede tener más

de un nombre constituido por enlaces físicos o simbólicos. A la hora de direc-

cionar un fichero se pueden utilizar nombres absolutos o relativos. Cada uno

de los nombres de subdirectorios que componen el nombre de un fichero se

encuentran separados por el carácter /.

Cada dispositivo de almacenamiento puede contener un SF que se crea mediante

la utilidad mkfs. Esta utilidad creará dentro del dispositivo la estructura del di-

rectorio, las estructuras de datos necesarias para gestionar el espacio libre y las es-

tructuras para almacenar las características de los ficheros (denominadas inodes),

como pueden ser el espacio que ocupará un fichero, o qué major y minor hay que

utilizar para localizar un dispositivo, quién es su propietario, etc.

A pesar de que cada dispositivo que contiene un SF cuenta con su propia es-

tructura de directorios, UNIX da la visión de un espacio en forma de grafo to-

Podéis ver las operaciones de acceso a los ficheros en el subapartado 4.2. del módulo didáctico “Los dispositivos de entrada/salida”.

Podéis ver los ficheros ejecutables en el subapartado 2.5. del módulo didáctico “El sistema operativo:una máquina virtual”.

Podéis ver el SF con la estructura de grafo dirigido en el subapartado 3.2. de este módulo didáctico.

Podéis ver los conceptos de major y el minor en el apartado 5 del módulo didáctico “Los dispositivosde entrada/salida”.


talmente conectado, lo cual significa que hay un único directorio raíz y que

siempre existe un camino desde este directorio raíz hasta cualquier fichero,

como se puede ver en la figura 10.

Para poder dar esta visión única, el sistema posee un SF permanentemente ac-

cesible* sobre el cual se irán añadiendo el resto de los SF antes de poder acceder

a ellos. La operación mount se encarga de asociar el directorio raíz del disposi-

tivo que se quiere montar con un directorio de un dispositivo que ya esté

montado. Aparte de esto, la operación mount lleva a cabo operaciones de ini-

cialización de estructuras internas del SO que agilizan los accesos.

Las llamadas al sistema y las órdenes que nos ofrece UNIX para gestionar el SF si-

guen la misma estructura que hemos descrito en el apartado del espacio de nom-

bres. Esta estructura es la que os presentamos a continuación en la siguiente tabla:

Operación Llamada al SO Orden Comentarios

Crear_SF – mkfs –

Montar_SF mount mount –

* El SF del sistema se ha montado en el tiempo de inicialización

del sistema.

Figura 6

Podéis ver el espacio de nombresen el apartado 3 de este módulo didáctico.


5.2. El mecanismo de protección de UNIX

Las protecciones en UNIX se basan en el modelo mixto, y nosotros nos cen-

traremos en las LCA y las operaciones que se ofrecen para gestionarlas.

En UNIX los dominios de protección se encuentran asociados a usuarios (UID)

y a grupos de usuarios (GID). Los grupos de usuarios son dominios en los que

se organizan los usuarios del sistema en función de sus características, del tra-

bajo que tienen que hacer, etc. Un usuario se identifica en el sistema mediante

un nombre de usuario y una contraseña. Una vez dentro del sistema, todos sus

procesos tendrán asociados los dominios de usuario y de grupo de usuarios al

que pertenezca. En un momento determinado, un usuario sólo puede perte-

necer a un grupo; asimismo, puede estar autorizado a cambiar de grupo me-

diante la orden newgrp.

Todos los ficheros se encuentran asociados al dominio de usuario y de grupo

de usuarios de su propietario. Para determinar los derechos de un usuario so-

bre un fichero, UNIX utiliza una LCA con tres dominios: el usuario propietario

del fichero, los usuarios que pertenecen al mismo grupo que el propietario y,

por último, cualquier otro usuario. Para cada uno prevé tres derechos diferen-

tes: de lectura, de escritura y de ejecución.

La visualización de las LCA se realiza mediante tres grupos de tres caracteres

cada uno, uno para cada derecho, como se muestra en la figura 7. El primer

grupo hace referencia al propietario; el segundo, al grupo del propietario, y el

Operación Llamada al SO Orden Comentarios

Desmontar_SF unmount unmount –

Verificar_SF – fsck –

Localizar_objeto – – –

Modificar_nombre – mv –

Crear_nombre link ln Crean enlaces

symlink –

mkdir mkdir Crean directorios

mknod mknod Crean dispositivos

Destruir_nombre unlink rm –

rmdir rmdir –

Ver_nombres read ls –

Cambio_de_directorio chdir cd –

Directorio_actual – pwd –

Podéis ver el modelo mixto en el subapartado 4.5. de este módulo didáctico.

Todos los estudiantes...

... que se hayan dado de alta en un sistema tendrán un dominio propio, y podrían estar organizados en un dominio conjunto denominado estudiantes.


tercero, al resto. Las letras r,w y x (lectura, escritura y ejecución) determinan

si se tiene el derecho, y la orden chmod permite al propietario conceder o re-

vocar estos derechos.

El derecho de ejecución se puede ver reforzado con el derecho setuid o con

el derecho setgid, los cuales permiten que durante la ejecución de un pro-

grama el proceso que lo ejecuta cambie respectivamente al dominio del usua-

rio propietario o al del grupo del usuario propietario del fichero ejecutable.

Estos derechos permitirán construir aplicaciones que accedan de manera con-

trolada a bases de datos o a ficheros en general sobre los cuales no se quiere

dar un derecho de escritura generalizado.

El significado de los derechos r,w y x varía si el fichero es un directorio. En

este caso, el derecho de lectura permite visualizar los nombres contenidos en el

directorio, el derecho de escritura permite añadir nombres nuevos al directorio

y, para finalizar, el derecho de ejecución hace posible que el usuario utilice el

directorio como un directorio de trabajo.

Figura 7


Resumen

En este módulo hemos estudiado el concepto de sistema de ficheros, median-

te el cual hemos visto que el SO ofrece a los usuarios los siguientes aspectos:

• el concepto de fichero;

• la gestión de los nombres de los ficheros;

• el mecanismo de protección que los ficheros tienen asociado.

Hemos extendido estos dos últimos puntos a todos los objetos que gestiona el

SO. Con respecto a los ficheros, hemos visto que el SO puede distinguir los di-

ferentes tipos de ficheros y que las operaciones de acceso que se pueden realizar

no siempre son las mismas.

Del mismo modo, hemos podido observar que la misión básica de los espacios

de nombres es implementar una función de traducción que permita utilizar

nombres estructurados y próximos a nuestras costumbres. Para conseguirlo,

podemos utilizar básicamente dos esquemas: el espacio lineal y el espacio je-

rárquico. Este último es el más utilizado en su variante de grafo dirigido.

Finalmente, hemos analizado dos mecanismos de protección: las listas de

control de accesos y las capabilities, y hemos podido comprobar que ambos

mecanismos presentan inconvenientes, motivo por el cual la mejor solución

es combinarlos.

Como caso concreto, hemos analizado el sistema de ficheros y el mecanismo de

protección de UNIX, de los cuales podemos destacar los siguientes elementos:

• Un SF con estructura de grafo conexo (con un único directorio raíz) que

agrupa ficheros y dispositivos.

• Un mecanismo de protección basado en las LCA que combina el uso en-

cubierto de capabilities en los file descriptors.


Actividades

1. Estudiad en el manual qué tipos de SF soporta LINUX.

2. Analizad las órdenes de UNIX que hemos presentado a lo largo de este módulo.

3. Pensad qué llamadas al SO debemos utilizar y cómo tenemos que realizar las órdenes ana-lizadas en la actividad anterior.

4. Como usuarios de Windows 95, analizad qué espacio de nombres y qué operaciones tenéispara acceder al SF desde las ventanas.

Ejercicios de autoevaluación

1. ¿Qué características o propiedades principales posee un fichero? Comentad también cuá-les pueden ser sus funciones.

2. Sobre la base de lo que hemos visto en este módulo didáctico y de vuestra propia experien-cia, estableced qué tipo de espacio de nombres presentan los sistemas de ficheros de los si-guientes SO:a) Windows 95.b) MS-DOS.c) UNIX.

3. ¿Qué tipo de enlace representan los ficheros que tienen la característica “acceso directo”de Windows 95? Justificad la respuesta.

4. En MS-DOS los directorios, además de la función de traducción, contienen la informaciónsobre las características de los ficheros a que hacen referencia, como pueden ser el númerode caracteres que contiene el fichero. ¿Qué inconvenientes puede suponer este hecho?

5. ¿Qué tipo de espacio de nombres creéis que es el más adecuado para los siguientes tiposde objetos?a) Ficheros.b) Dispositivos físicos o lógicos.c) Dispositivos virtuales.d) Procesos.e) Usuarios.

6.¿Cómo sería la siguiente matriz si...a) cada usuario sólo pudiese acceder a sus ficheros con todos los derechos (lectura, escrituray ejecución)?b) el conjunto total de usuarios pudiese acceder con todos los derechos a todos los ficheros?

7. En los dos casos del ejercicio 6, ¿es necesario tener un mecanismo de protección? Y en casode que sea necesario, ¿tiene sentido el derecho de propietario? Justificad la respuesta.

8. En el sistema Windows 95, ¿qué mecanismo de protección creéis que hay? ¿Cuántos do-minios prevé el sistema de protección? Justificad la respuesta.

9. Indicad en qué momentos de una sesión de trabajo con un fichero se verifican los dere-chos de acceso si tenemos un sistema operativo con un sistema de protección basado en...a) LCA.b) listas de capabilities.Justificad las respuestas.

10. ¿Qué restricciones tiene el mecanismo de protección de UNIX con respecto a un mecanis-mo de LCA en el que cada usuario constituye en sí mismo un dominio? Justificad la respuesta.

Dominios Objetos

Fichero A Fichero B Fichero C Fichero D Fichero E Fichero F Fichero G Fichero H

Juan Propietario Propietario

María Propietario Propietario

José Propietario Propietario

Marta Propietario Propietario


Solucionario

Ejercicios de autoevaluación

1. Un fichero tiene un conjunto de características o propiedades que hacen referencia a lossiguientes aspectos:a) La información relativa al contenido del fichero y a su modificación: tamaño del fichero, fe-cha de creación, última fecha de acceso, última fecha de modificación, tipo de información, etc.Su función es básicamente estadística, a excepción del tamaño del fichero y del tipo de informa-ción. El sistema utiliza el tamaño del fichero para determinar cuándo tiene que dar la marca definal de fichero durante los accesos de lectura. El tipo de información que contiene el fichero tie-ne la posibilidad de condicionar las operaciones que se pueden realizar en el mismo. b) La ubicación de esta información dentro del dispositivo de almacenamiento.Contiene información necesaria para que el sistema pueda localizar el fichero dentro del dis-positivo de almacenamiento.c) La accesibilidad del fichero.Contiene información relacionada con el usuario propietario del fichero y las operacionesque se pueden realizar en el mismo: escribir, leer, ejecutar, etc. Todas estas informaciones es-tán relacionadas con el mecanismo de protección.

2. a) Windows 95 posee un espacio de nombres en forma de grafo dirigido en el que se puedenformar ciclos, puesto que un fichero puede tener más de un nombre gracias a los apuntadoressimbólicos. El espacio es disjunto: cada dispositivo que contiene un sistema de fichero tieneun espacio de nombres separado.b) El espacio de nombres de MS-DOS tiene forma de árbol si no consideramos los nombres“.” y “..” que poseen los directorios, ya que no permiten que los ficheros tengan más de unnombre. Si consideramos los nombres “.” y “..” de los directorios, entonces tiene un espaciode nombres en forma de grafo dirigido. Como en el caso de Windows 95, cada dispositivoque contiene un sistema de ficheros posee un espacio de nombres separado.c) UNIX tiene un espacio de nombres con las mismas características que Windows 95, conla diferencia de que en UNIX los ficheros pueden tener más de un nombre gracias a los en-laces simbólicos y a los físicos. Además, en UNIX el espacio no está disjunto, sino que hayun solo espacio que une todos los dispositivos activos que contienen un sistema de fichero.

3. Los ficheros de acceso directo de Windows 95 presentan enlaces simbólicos, unos enlacesque hacen referencia a un fichero mediante otro nombre del espacio de nombres. Cuando seborra el fichero por medio del enlace físico, los accesos directos se mantienen, ya que no se pue-den localizar con facilidad a partir del fichero borrado. Cuando se accede por el nombre de ac-ceso directo, el sistema se da cuenta de que no existe el fichero y avisa de esta circunstancia.

4. El principal inconveniente de este hecho es que se mezcla el concepto de función de tra-ducción con la estructura del fichero, circunstancia que provoca una pérdida de flexibilidaden el espacio de nombres. Con un sistema de estas características no se puede asignar más deun nombre a un fichero, ya que en caso de hacerlo se duplicaría la información, con el riesgoo el coste de mantenerla coherente. Por ejemplo, en MS-DOS se guarda el número de carac-teres en el directorio; si tenemos dos nombres para el mismo fichero, tendremos también doscopias de este número, y si éste se actualiza en función del nombre por el cual se accede alfichero, nos podemos encontrar con informaciones incoherentes.

5. Todas las decisiones dependerán en gran medida del volumen de objetos que se quiere di-reccionar mediante los espacios de nombres y del tipo de usuario de estos objetos.a) Ficheros: tal y como se ha visto en el módulo, lo más adecuado es un espacio jerárquicoen forma de grafo, que proporciona la máxima flexibilidad a la hora de organizar los objetos.Los nombres tienen que estar formados por cadenas de caracteres para que se puedan adaptara nuestras necesidades, ya que, en general, los usuarios somos las personas, y el volumen deficheros que se quiere direccionar es importante. b) Dispositivos físicos o lógicos: en este caso puede ser suficiente un espacio con estructuraen árbol o un espacio lineal, puesto que las necesidades de organización de los objetos noson tan importantes como en el caso anterior porque el volumen de objetos es mucho me-nor. Debido a que los usuarios somos las personas, igual que en el caso anterior, sería conve-niente que los nombres los formasen cadenas de caracteres.c) Dispositivos virtuales: el espacio más indicado es el espacio lineal con nombres sencillos,como pueden ser números, a causa del hecho de que los usuarios de este tipo de dispositivosson los procesos; además, los dispositivos virtuales visibles desde un proceso no necesitan servisibles desde los otros. Se trata de un conjunto de objetos reducido y con unas necesidadesde organización muy bajas.d) Procesos: con un espacio lineal con nombres sencillos, como números, es suficiente, yaque igual que en el caso anterior, nos encontramos con un conjunto de objetos direcciona-


dos casi en exclusiva por el SO o por los procesos. El número de objetos puede ser importante,pero carecen de necesidades de organización.e) Usuarios: lo más adecuado es un espacio lineal. Los nombres tendrían que estar formados porcadenas de caracteres en consideración a los usuarios humanos, puesto que en este caso los usuariosson los objetos dominio y los usuarios de estos objetos dominio pueden ser las personas y el siste-ma. El número de objetos puede ser muy grande, pero la necesidad de organización es pequeña.Finalmente, hay que tener presente que, en todos los casos en que se ha propuesto un espaciocon nombres formados por cadenas de caracteres, hay que disponer de un segundo espacio denombres interno, por lo general lineal y con nombres basados en números, próximo a las ne-cesidades de gestión del SO. Los nombres de este espacio interno son aquéllos a los que hacereferencia la función de traducción una vez se ha traducido un nombre del espacio externo.

6.a) Si cada usuario sólo pudiese acceder a sus ficheros con todos los derechos (lectura, escritu-ra y ejecución), la matriz de accesos sería la siguiente:

b) Si el conjunto completo de usuarios pudiese acceder con todos los derechos a todos losficheros, la matriz de acceso sería:

Dominios Objetos


Juan PropietarioLecturaEscrituraEjecución

PropietarioLecturaEscrituraEjecución

María PropietarioLecturaEscrituraEjecución


José PropietarioLecturaEscrituraEjecución


Marta PropietarioLecturaEscrituraEjecución


Dominios Objetos


Juan PropietarioLecturaEscrituraEjecución


LecturaEscrituraEjecución






María LecturaEscrituraEjecución








José LecturaEscrituraEjecución








Marta LecturaEscrituraEjecución









7. a) En el caso de que cada usuario sólo pueda acceder a sus ficheros con todos los derechos(lectura, escritura y ejecución), efectivamente es necesario un mecanismo de protección lomás restrictivo posible, que no permitiese compartir ficheros entre usuarios. De este modo,el derecho del propietario está implícito en la estructura del mecanismo propuesto y, en con-secuencia, su existencia explícita no es importante. b) En caso de que el conjunto de usuarios pueda acceder con todos los derechos a todos losficheros, no existe ningún mecanismo de protección, ya que todos los usuarios podrán hacerlo que quieran sobre cualquier fichero. Así, al no ser necesario ningún mecanismo de protec-ción, tampoco se precisa el derecho del propietario.

8. En Windows 95 encontramos un mecanismo de protección muy parecido al que hemos des-crito en el apartado a) del ejercicio 7, y el sistema de protección prevé un único dominio deprotección. En este caso, las protecciones tienen la finalidad de evitar que los miembros delúnico dominio que existe puedan realizar alguna operación que no deseen en un descuido.

9. a) En el caso de la LCA: aquí, la verificación de derechos se lleva a cabo en cada acceso aldispositivo, puesto que la información de protección se encuentra físicamente en el disposi-tivo. Esto significa que, en un SO con un mecanismo de protección basado exclusivamenteen LCA, hay que verificar todos los accesos al fichero de una sesión de trabajo.b) En el caso de las listas de capabilities: ahora la verificación de derechos se encuentra aso-ciada al proceso que quieren efectuar los accesos. Esta verificación se lleva a cabo de acuerdocon la existencia o no de la capability asociada al objeto. Así pues, en un SO basado exclusi-vamente en capabilities, en una sesión de trabajo sólo hay que verificar el derecho de accesoen la operación de abrir, que se encarga de verificar la existencia de la capability.

10. En un mecanismo como el de UNIX, los dominios que recogen las LCA se han restringidoa los tres siguientes: propietario, grupo del propietario y el resto de los usuarios. Esta simpli-ficación de todos los dominios posibles hace que UNIX pueda realizar una gestión de las pro-tecciones más eficiente con respecto al espacio y al tiempo de gestión. A pesar de esto, lasimplificación que acabamos de ver restringe la flexibilidad a la hora de especificar los dere-chos individuales de cada usuario. Por ejemplo, con UNIX no es posible distinguir entre losusuarios que pertenecen al grupo y el propietario y, por tanto, no se les puede dar derechosdiferentes, y lo mismo sucede con los usuarios que pertenecen al dominio “el resto de losusuarios”. De todos modos, esta restricción se puede suavizar con una buena política de de-finición de grupos de usuarios, ya que un usuario de UNIX puede estar autorizado, dentro deun conjunto predeterminado, a cambiar de grupo de usuarios.

Glosario

directorioFicheros en los que se almacena la estructura de datos que da lugar a la función de traducción.

directorio de trabajoDirectorio en el que se encuentran los ficheros con los cuales un usuario está trabajando enun instante concreto. Cuando un usuario empieza la sesión de trabajo, el directorio de tra-bajo es el directorio inicial.

directorio inicialDirectorio desde donde un usuario puede crear su estructura de directorios y donde colocarálos ficheros que él cree.

dominio Agentes activos del sistema que pueden actuar sobre un objeto.

derechoAcciones que permite un dominio sobre un objeto.

enlace físicoEnlace que relaciona directamente un nombre del sistema de ficheros con el objeto al quehace referencia; o, lo que es lo mismo, relaciona directamente un nombre del sistema de fi-cheros con el nombre interno del SO del objeto al que hace referencia.

enlace simbólicoEnlace que no relaciona de manera directa un nombre del sistema de ficheros con un objeto,sino que lo hace indirectamente mediante un enlace a otro nombre del sistema de ficherosdesde el cual se puede localizar el objeto. Este tipo de enlaces se utiliza fundamentalmente


para dar un nombre a un objeto que se encuentra en un dispositivo de almacenamiento di-ferente de aquél en el que se encuentra el directorio que contiene el enlace simbólico.

espacio de nombresEspacio configurado por el conjunto de todos los nombres posibles de un objeto.

espacio de nombres jerárquicoEspacio formado por una jerarquía de directorios, con un directorio raíz del cual cuelganotros directorios o ficheros que configuran las hojas del árbol. Los espacios jerárquicos pue-den tener forma de árbol o, de forma más general, de grafo dirigido.

espacio de nombres linealEspacio de nombres, con una sola dimensión, donde todos los nombres se encuentran al mis-mo nivel, en un único directorio. En este tipo de espacio no se pueden hacer clasificacionesentre los diferentes objetos.

ficheroDispositivo lógico formado por una agrupación lógica de información almacenada en un dis-positivo físico, como puede ser un disco, una cinta o la memoria, y que puede ser manipuladacomo un todo. La información que incluye tiene en común un conjunto de propiedades quela caracterizan.

función de traducciónFunción unívoca que relaciona un nombre con un objeto.

LCAVed lista de control de accesos.

lista de capabilitiesLista de parejas (objeto, derechos) asociada a un dominio. Cada una de estas parejas se deno-mina capability. Las listas de capabilities son el resultado de dividir la matriz de accesos en filasy eliminar, igual que en las listas de control de acceso, todas las celdas vacías.

lista de control de accesos Lista de parejas (derechos, dominio) asociada a un objeto. Esta lista se obtiene como resultadode dividir la matriz en accesos en columnas y eliminar todas las celdas vacías.Sigla: LCA

llave y cerrojoMecanismo de revocación de derechos basado en el uso de parejas de nombres denominadascerrojo y llave, que tienen que coincidir para dar por válido un derecho. Si estos números nocoinciden, el derecho quedará invalidado.

matriz de accesosMatriz formada por tantas filas como dominios (Di), y tantas columnas como objetos (Oj),donde cada celda Dij contiene los derechos de acceso del dominio Di sobre el objeto Oj.

nombre absolutoNombre formado por la ruta que va desde la raíz, pasando por los diferentes subdirectorios,hasta llegar al fichero. Así pues, el nombre absoluto está compuesto por una secuencia de ca-denas de caracteres o componentes del nombre contenidos en los subdirectorios que confi-guran la ruta. Estos componentes se encuentran separados por un carácter delimitador.

nombre relativoNombres formados por el recorrido que va desde el directorio de trabajo hasta el fichero. Di-ferentes ficheros pueden tener el mismo nombre relativo, siempre que éste se obtenga a par-tir de directorios de trabajo diferentes.

objetoElemento que gestiona el SO sobre el cual se pueden llevar a cabo acciones en función deunos derechos.

sistema de ficherosSistema que se encarga de gestionar el conjunto de ficheros contenido en un mismo dispo-sitivo de almacenamiento.


Bibliografía

Bibliografía básica

Milenkovic, M. (1994). Sistemas operativos, conceptos y diseño (2.ª ed.; trad. de A. Bautista).Madrid: McGraw-Hill.

Silberschatz, A.; Peterson, J.; Galvin, P. (1994). Sistemas operativos, conceptos fundamen-tales (3.ª ed.; trad. de E. Morales). Wilmington: Addison-Wesley Iberoamericana.

Tanenbaum, A. (1993). Sistemas operativos modernos (trad. de O. Palmas). México: PrenticeHall Hispanoamericana.

Bibliografía complementaria

Deitel, H. (1993). Introducción a los sistemas operativos (2.ª ed.; trad. de R. Escalona). Argen-tina: Addison-Wesley Iberoamericana.

Robbins, K.; Robbins, S. (1997). UNIX: programación práctica. México: Prentice Hall His-panoamericana.

sistemas operativos mod5

Documents