Archivos POSIX y sus operaciones Archivos Windows. Procesos e hilos.MIRCOLES 15 DE OCTUBRE DE 2008

Procesos e hilos de ejecucion en Windows (I)Podemos definir un proceso como una instancia para un programa en ejecucin, e instancia es la palabra adecuada dado que, como la mayora de elementos en Windows, para el kernel o ncleo del sistema un proceso no es ms que un tipo de objeto determinado. Aunque parezcan similares debemos distinguir de forma clara las diferencias existentes entre un proceso y un programa: Un programa es una secuencia esttica de instrucciones, organizadas de forma secuencial.

Un proceso es un contenedor para los recursos y dems elementos que sern utilizados por los hilos (o threads), encargados de ejecutar las instrucciones que componen el programa.

De las definiciones anteriores podemos desprender que un proceso en s mismo es inservible, a menos que contenga un hilo o thread, el cual ser utilizado por Windows para planificar la ejecucin del programa. El sistema de planificacin de Windows se basa en prioridades, de forma que la CPU se encarga de asignarles un tiempo basndose en dicha prioridad. De esta forma, cada uno de los threads que componen los diferentes procesos del sistema se ejecutan en "gajos" de tiempo (conocidos internamente como quantums) siguiendo un algoritmo round-robin, y dando la impresin de que lo hacen de forma concurrente. Windows Debugging Tools Para poder ver las estructuras de datos manejadas internamente por el kernel

necesitaremos tener instaladas las Microsoft Debugging Tools. Una vez descargados los binarios adecuados para nuestro tipo de arquitectura (32 o 64 bits) aparecer una nueva entrada en la lista de programas del men Inicio que se corresponder con los binarios que componen el debugger de Microsoft. Existen dos versiones diferentes del debugger, ambas con funcionalidades similares y que nicamente se diferencian en el tipo de interfaz utilizada:

kd.exe: versin de lnea de comandos

windbg.exe: versin con entorno grfico

Por otra parte, y para poder analizar correctamente las estructuras internas del kernel ser necesario contar con la versin adecuada de los ficheros de smbolos (symbols). Dichos ficheros contienen los nombres de variables y funciones, son generados por el linker y los utiliza el debugger para mostrar los nombres adecuados durante una sesin de debug. Esta informacin no se almacena en la imagen binaria del kernel dado que no resulta necesaria para la ejecucin del mismo y la mejor opcin es la de cargarlos bajo demanda desde el servidor de Microsoft mediante la variable "symbol path" utilizada por el debugger. Vamos a describir a continuacin el proceso de configuracin de la versin grfica para realizar una sesion de debugging local del kernel. Abriremos el programa WinDbg mediante el acceso directo del men Inicio. Una vez abierto accederemos al men File - Symbol File Path. All incluiremos lo siguiente: SRV*C:\websymbols*http://msdl.microsoft.com/donwload/symbols Una vez incluido pulsaremos OK y accederemos al men File - Save Workspace. De esta forma no ser necesario volver a introducir el parmetro para cada sesin. Lanzaremos ahora la sesin de debugging local del kernel mediante el men File - Kernel Debug. En el cuadro de dilogo seleccionaremos la pestaa Local pulsando el botn Aceptar para obtener la lnea de ejecucin de comandos y la ventana de resultados.

Pasos bsicos de creacin de un proceso Para crear un proceso se realiza una llamada a cualquiera de las funciones de creacin de Windows:

CreateProcess CreateProcessAsUser CreateProcessWithTokenW CreateProcessWithLogonW

Los pasos indicados a continuacin implican la participacin de tres componentes del sistema operativo: la parte cliente de la librera kernel32.dll, el Windows Executive y el proceso de subsistema de Windows (Csrss). Resumen de las fases en que se divide la creacin de un proceso: 1. Abrir el fichero de imagen (.exe) que se ejecutar mediante el proceso.

2. Crear el objeto para el bloque ejecutivo de proceso (_EPROCESS).

3. Crear el hilo de ejecucin primario (pila, contexto y bloque ejecutivo dehilo _ETHREAD).

4. Comenzar la ejecucin del hilo primario.

5. En el contexto del nuevo proceso y su hilo asociado completar la inicializacin del espacio de direcciones (p.e. mediante la carga de las DLL requeridas) y empezar la ejecucin del programa.

Estructuras internas de datos Vamos a analizar la estructura interna para los diferentes bloques ejecutivos, _EPROCESS y _ETHREAD, y que seran las representaciones manejadas por el kernel de Windows para los procesos e hilos de ejecucin respectivamente.

Los comandos a ejecutar en el debugger del kernel que iniciamos en una de las anteriores secciones seran:lkd> dt -a -b -v _EPROCESS lkd> dt -a -b -v _ETHREAD

S que la informacin incluida en esta ltima seccin es muy escueta, por lo que prometo desarrollarla ms a fondo en prximas entradas.

Listas de control de acceso POSIX en LinuxAndreas Grnbacher SuSE Labs, SuSE Linux AG de Nuremberg, Alemania agruen@suse.de Resumen: Este documento analiza el sistema de archivos Access Control Lists tal como se aplica en varios sistemas operativos tipo UNIX. Despus de recapitular los conceptos de estas listas de control de acceso que nunca se convirti formalmente en un estndar POSIX, nos centramos en los diferentes aspectos de la aplicacin y uso en Linux.

IntroduccinTradicionalmente, los sistemas que apoyan el POSIX (Portable Operating System Interface) de la familia de las normas [ 11 , 2 ] compartir una sencilla pero potente sistema de archivos modelo de permisos: Cada objeto del sistema de archivo est asociado con tres conjuntos de permisos que definen el acceso para el propietario, el grupo propietario, y para los dems. Cada conjunto puede contener Leer (r), escritura (w) y ejecucin (x) permisos. Este esquema se realiza utilizando slo nueve bits para cada objeto. Adems de estos nueve bits, el ID usuario, ID grupo, y los bits de adhesivos utilizados para una serie de casos especiales. Muchos textos introductorios y avanzados en el sistema operativo UNIX describir este modelo [ 19 ]. Aunque el modelo tradicional es muy simple, es suficiente para la aplicacin de los escenarios de permisos que normalmente se producen en los sistemas UNIX. Los administradores de sistemas tambin han encontrado varias soluciones para las limitaciones del modelo. Algunas de estas soluciones requieren configuraciones de grupo que no obvias pueden no reflejar las estructuras organizativas. Slo el usuario root puede crear grupos o la pertenencia a grupos cambio. utilidades Set-ID de usuario root puede permitir que los usuarios normales para realizar algunas tareas administrativas, pero los errores en los servicios pblicos como puede llevar fcilmente a los sistemas comprometidos. Algunas aplicaciones como demonios FTP implementar sus propias extensiones al sistema de modelo de permiso de archivo [15 ]. El precio de jugar trucos con los permisos de un aumento de la complejidad de la configuracin del sistema. La comprensin y el mantenimiento de la integridad de los sistemas se hace ms difcil. Los ingenieros han reconocido desde hace tiempo las deficiencias del modelo tradicional de permisos y han empezado a pensar en otras alternativas. Esto ha dado lugar finalmente en una serie de Access Control List (ACL) de las implementaciones de UNIX, que slo son compatibles entre s en un grado limitado. Este documento ofrece una visin general del rgimen de ACL de mayor xito para los sistemas tipo UNIX que ha resultado de la POSIX 1003.1e/1003.2c grupo de trabajo. Despus de una breve descripcin de los conceptos, algunos ejemplos de cmo estos se utilizan se dan para una mejor comprensin. A continuacin, el documento analiza atributos extendidos, la capa de abstraccin sobre la cual ACL se basan en Linux. El resto del artculo trata de la aplicacin, el rendimiento, la interoperabilidad, soporte de aplicaciones, y los aspectos de mantenimiento del sistema de ACL. El autor particip en el diseo e implementacin de los atributos extendidos y ACL en Linux, que abarca las herramientas de usuario y la implementacin del ncleo para ext2 y ext3, el ms destacado de los sistemas de archivos Linux. Partes del diseo de la interfaz de llamada al sistema se le atribuyen a Linux de Silicon Graphics proyecto de XFS, en particular con Nathan Scott.

El POSIX Grupo de Trabajo 1003.1e/1003.2cUna necesidad para la normalizacin de otras reas de seguridad pertinentes, adems de ACL slo fue percibido tambin, por lo que finalmente un grupo de trabajo formado para definir las extensiones de seguridad en el POSIX 1003.1 familia de normas. Los nmeros de documento 1003.1e (Sistema de Application Programming Interface) y 1003.2c (Shell y utilidades) fueron asignados para las especificaciones del grupo de trabajo. Estos documentos se refieren a POSIX.1e como en el resto de este artculo. El grupo de trabajo se centra en las siguientes extensiones a POSIX.1: Access Control Lists (ACL), Auditora, capacidad, control de acceso obligatorio (MAC), e informacin de etiquetado. Desafortunadamente, con el tiempo result que la normalizacin de todas estas diversas reas fue un objetivo demasiado ambicioso. En enero de 1998, el patrocinio de 1003.1ey 1003.2c fue retirada. Si bien algunas partes de los documentos presentados por el grupo de trabajo hasta entonces ya estaban de alta calidad, el conjunto de obras no estaban listos para su publicacin como normas. Se decidi que el proyecto de 17, la ltima versin de los documentos que el grupo de trabajo haba producido, debe ser puesto a disposicin del pblico. Hoy en da, estos documentos se pueden encontrar en la web del sitio Trmper Winfried [ 27 ]. Varios fabricantes de sistemas UNIX han implementado diversas partes de las extensiones de seguridad, aumentada por las extensiones especficas del proveedor. Las versiones resultantes de sus sistemas operativos a menudo han sido calificados de confianza'', `` los sistemas operativos, por ejemplo, Trusted Solaris, Irix de confianza, de confianza AIX. Algunos de estos `` confianza''caractersticas han sido posteriormente incorporados a los sistemas de los proveedores principales de funcionamiento. ACL se apoyan en diferentes tipos de archivos de sistema en casi todos los sistemas UNIX-como hoy en da. Algunas de estas implementaciones son compatibles con el proyecto 17 del pliego de condiciones, mientras que otros se basan en mayores corrientes de aire. Desafortunadamente, esto ha dado lugar a una serie de diferencias sutiles entre las diferentes implementaciones. El proyecto TrustedBSD ( http://www.trustedbsd.org/ ) dirigida por Robert Watson ha puesto en marcha las versiones de la ACL, capacidades, MAC y Auditora partes de POSIX.1e para FreeBSD. Las implementaciones de ACL y MAC aparecer en FreeBSD-RELEASE a partir de enero de 2003. La aplicacin del MAC todava se considera experimental.

Condicin Jurdica y Social de las ACL en LinuxLos parches que implementan POSIX 1003.1e proyecto de 17 ACL han estado disponibles para varias versiones de Linux desde hace varios aos. Ellos se han aadido a la versin 2.5.46 del kernel de Linux en noviembre de

2002. Actuales distribuciones de Linux an se basan en la serie de kernels 2.4.x estable. SuSE y el consorcio United Linux han integrado la ACL del ncleo 2.4 parches antes que otros, por lo que sus productos actuales ofrecen el soporte de ACL ms completa disponible para Linux hasta la fecha. Otros proveedores al parecer siguen siendo reacios a hacer ese cambio importante, pero las versiones experimentales se espera que est disponible a finales de este ao. El getfacl Linux y setfacl utilidades de lnea de comando no siguen estrictamente POSIX 1003.2c proyecto de 17, que muestra sobre todo en la forma en que manejan las ACL por defecto. Vea la seccin 6. En el momento de escribir estas lneas, soporte de ACL en Linux est disponible para el tipo ext2, ext3, IBM JFS, ReiserFS, y SGI sistemas de archivos XFS. soporte ACL Solaris compatible con la versin 3 de NFS existe desde el 03 de marzo 2003.

Cmo ACL TrabajoEl modelo tradicional de sistema de archivo de modelo de objetos de autorizacin define tres categoras de usuarios llamado propietario, grupo y otros. Cada una de estas clases se asocia con un conjunto de permisos. Los permisos definidos son de lectura (r), escritura (w) y ejecucin (x). En este modelo, los permisos de la clase propietaria definir los privilegios de acceso del propietario del fichero, los permisos de clase de grupo define los privilegios de acceso del grupo propietario y los permisos de otra clase definir los privilegios de acceso de todos los usuarios que no estn en uno de estos dos clases. El comando muestra l-ls el propietario, grupo y otros permisos de la clase en la primera columna de su produccin (por ejemplo, ``-rwr--''para un archivo normal con lectura y escritura para la clase propietaria, acceso de lectura para la clase de grupo, y sin acceso para los dems). Una ACL consiste en un conjunto de entradas. Los permisos de cada objeto del sistema de archivos tienen una representacin ACL, incluso en el caso mnimo, POSIX.1-solamente. Cada una de las tres clases de usuarios est representado por una entrada de ACL. Permisos para los usuarios o grupos adicionales ocupan ms de las entradas ACL. La Tabla 1 muestra los tipos de entrada definido y sus formas de texto. Cada una de estas entradas se compone de un tipo, un calificativo que especifica a qu usuario o grupo de la entrada se aplica, y un conjunto de permisos. La clasificacin no est definida para las entradas que no requieren cualificacin. equivalente ACL con el permiso bits de modo de archivo se llama ACL mnima. Ellos tienen tres entradas ACL. ACL con ms de las tres entradas son llamados ACL extendida. ACL extendida tambin contienen una mscara de entrada y puede contener cualquier nmero de usuarios con nombre y nombre de las entradas de grupo.

Tabla: Tipos de entradas ACLEntrada de tipo Propietario Nombre de usuario Ser propietario de grupo Nombre del grupo Mscara Otros Formulario de texto usuario:: rwx usuario: nombre: rwx Grupo:: rwx grupo: nombre: rwx mscara:: rwx :: Rwx otros

Estos grupos con nombre y nombre de las entradas de usuario se asignan a la clase de grupo, que ya contiene la entrada del grupo propietario. Diferente del modelo de permiso POSIX.1, la clase de grupo ahora puede contener entradas ACL con conjuntos de permisos diferentes, por lo que los permisos de clase solo grupo ya no son suficientes para representar a todos los permisos detallada de todas las entradas de ACL que contiene. Por lo tanto, el significado de los permisos de grupo de clase se redefine: bajo su nueva semntica, que representan un lmite superior de los permisos que cualquier entrada en la clase de grupo de subvencin. Esta propiedad del lmite superior garantiza que las aplicaciones POSIX.1 que no son conscientes de ACL no de repente e inesperadamente comienzan a conceder permisos adicionales una vez que son compatibles con ACL. En ACL mnima, los permisos de clase de grupo son idnticos a los permisos del grupo propietario. En ACL extendida, la clase de grupo puede contener entradas para los usuarios o grupos adicionales. Esto se traduce en un problema: algunas de estas entradas adicionales pueden contener permisos que no estn contenidos en la entrada del grupo propietario, por lo que el ser dueo de tus permisos de grupo pueden ser diferentes de los permisos de grupo clase. Este problema se resuelve por la virtud de la entrada de la mascarilla. Con ACL mnima, los permisos de clase de grupo mapa para los permisos de entrada de grupo propietario. Con ACL extendida, los permisos de clase de grupo mapa para los permisos de la mscara de entrada, mientras que la entrada del grupo propietario todava define los permisos del grupo propietario. La asignacin de los permisos de grupo de clase ya no es constante. La Figura 1 muestra estos dos casos.

Figura: asignacin entre las entradas ACL y bits de permiso delarchivo de modo

Cuando una aplicacin que cualquier cambio de propietario, grupo, u otros permisos de la clase (por ejemplo, mediante el comando chmod), la entrada correspondiente de los cambios de ACL tambin. Del mismo modo, cuando una aplicacin cambia los permisos de una entrada de ACL que se asigna a una de las clases de usuario, los permisos del cambio de clase. Los permisos de clase de grupo representan el lmite superior de los permisos concedidos por cualquier entrada en la clase de grupo. Con ACL mnima esto es trivial el caso. Con ACL extendida, esto se implementa mediante el enmascaramiento permisos (de ah el nombre de la mscara de entrada): los permisos de las entradas que son un miembro de la clase de grupo que tambin estn presentes en la entrada de la mscara son eficaces. Los permisos que estn ausentes en la entrada de la mscara se oculta y por lo tanto no surten efecto. Ver Tabla 2 .Tabla: Enmascaramiento de permisosEntrada de tipo Nombre de usuario Mscara Formulario de texto usuario: joe: rx mscara:: rwPermis os rx rwr-

permisos efectivos

El propietario y otras entradas no estn en la clase de grupo. Sus permisos siempre son efectivos y enmascarados nunca.

Hasta ahora slo hemos mirado ACL que definen los permisos de acceso actual de los objetos del sistema de archivos. Este tipo se llama acceso ACL. Un tipo llamado ACL por defecto segunda tambin est definido. Ellos definen los permisos que hereda un sistema de archivos objeto de su directorio padre en el momento de su creacin. directorios Slo se puede asociar con ACL predeterminada. ACL por defecto para los no-directorios sera de ninguna utilidad, porque no hay otro sistema de archivo de los objetos se pueden crear en el interior no directorios. ACL por defecto no juegan ningn papel directo en los controles de acceso. Cuando se crea un directorio dentro de un directorio que tiene una ACL por defecto, el nuevo directorio hereda la ACL del directorio principal por defecto tanto como su acceso ACL y ACL por defecto.Los objetos que no son directorios heredarn la ACL por defecto del directorio padre como su nico acceso ACL. Los permisos de acceso ACL heredadas son modificadas an ms por el parmetro de modo que cada sistema de llamadas de sistema de creacin de objetos de archivo. El parmetro modo contiene nueve bits de permisos que representan los permisos del propietario, grupo, clase y otros permisos. Los permisos efectivos de cada clase se establece en la interseccin de los permisos definidos para esta clase en el ligamento cruzado anterior y se especifica en el parmetro de modo. Si el directorio padre tiene ningn valor predeterminado ACL, los permisos del nuevo archivo se establecer de acuerdo con POSIX.1. Los permisos efectivos se establecen en los permisos definidos en el parmetro modo, menos los permisos establecidos en la umask actual. La mscara de usuario no tiene ningn efecto si un ACL por defecto existe.

COMPROBACIN DE ACCESO ALGORITMO

Un proceso de solicitudes de acceso a un objeto de sistema de archivos. Dos pasos se realizan. El primer paso selecciona la entrada de ACL que ms se acerque el proceso de su inters. Las entradas de ACL se mir en el siguiente orden: propietario, los usuarios con nombre, (que poseen o nombre) los grupos, otros. Slo una nica entrada determina el acceso. El segundo paso comprueba si la entrada a juego contiene suficientes permisos. Un proceso puede ser miembro en ms de un grupo, as que ms de una entrada de grupo pueden igualar. Si alguna de estas entradas de grupo se pongan en venta contienen los permisos solicitados, que contiene los permisos solicitados se recoge (el resultado es el mismo independientemente de la

entrada se recoge). Si ninguna de las entradas de grupo a juego contiene los permisos solicitados, el acceso ser denegado sin importar que la entrada es recogido. El algoritmo de comprobacin de acceso se puede describir en pseudo-cdigo de la siguiente manera. Si el ID de usuario del proceso es el propietario, el dueo de la entrada determina el acceso else if el ID de usuario del proceso coincide con la clasificacin en una de las entradas de usuario con nombre, esta entrada determina el acceso else if uno de los identificadores de grupo del proceso coincide con el grupo propietario y grupo propietario de la entrada contiene los permisos solicitados, esta entrada determina el acceso else if uno de los identificadores de grupo del proceso coincide con el calificativo de una de las entradas de grupo con nombre y esta entrada contiene los permisos solicitados, esta entrada determina el acceso else if uno de los identificadores de grupo del proceso coincide con el grupo propietario o cualquiera de las entradas de grupo con nombre, pero ni la entrada del grupo propietario ni ninguna de las entradas de grupo a juego con nombre contiene los permisos solicitados, lo que determina que el acceso es denegado ms la otra entrada determina el acceso. Si

la entrada a juego resultante de esta seleccin es la entrada del propietario o de otro tipo y que contiene los permisos solicitados, se concede el acceso else if la entrada a juego es un nombre de usuario, grupo propietario, o la entrada con nombre del grupo y esta entrada contiene los permisos solicitados y la mscara de entrada tambin contiene los permisos solicitados (o no hay ninguna entrada mscara), se concede el acceso ms se deniega el acceso.

Ejemplo de acceso ACLVamos a empezar por crear un directorio y comprobar sus permisos. La mscara de usuario determina qu permisos se enmascarados cuando el directorio se crea. Una umask de 027 (octal) deshabilita el acceso de escritura para el grupo propietario y leer, escribir y ejecutar el acceso a los dems.$ Umask 027 $ Mkdir dir dir $ ls-dl drwxr-x --- ...

suse agruen ...

dir

El primer carcter ls imprime representa el tipo de archivo (d para directorio). La cadena `` rwxr-x -''representa los permisos que resulta para el nuevo directorio: leer, escribir y ejecutar el acceso para el propietario y el acceso de lectura y ejecucin para el grupo propietario. Los puntos en la salida de ls soporte para el texto que no es relevante aqu y se ha quitado. Estos permisos de base tienen una representacin equivalente de una ACL. ACL se muestran con el comando getfacl.dir $ getfacl archivo #: dir # El propietario: agruen Grupo #: suse usuario:: rwx Grupo:: rx otros ::---

Las tres primeras lneas de salida conteniendo el nombre del archivo, el propietario y grupo propietario del archivo como comentarios. Cada una de las siguientes lneas contiene una entrada de ACL para una de las tres clases de usuarios: propietario, grupo y otros.

Las subvenciones siguiente ejemplo leer, escribir y ejecutar el acceso al usuario Juan, adems de los permisos existentes. Para ello, el m-(modificar) el argumento de setfacl se utiliza. La ACL resultante se muestra de nuevo con el comando getfacl. El omitir encabezado opcin a getfacl suprime la lnea de comentario de cabecera y tres que contiene el nombre del archivo, el propietario y grupo propietario de acortar los ejemplos mostrados.usuario $ setfacl-m: joe: dir rwx $ Getfacl - dir omitir-cabecera usuario:: rwx usuario: joe: rwx Grupo:: rx mscara:: rwx otros ::---

Dos entradas adicionales han sido aadidos a la lista ACL: uno es para el usuario Juan y la otra es la entrada de la mascarilla. La mscara de entrada se crea automticamente cuando es necesario pero no suministrado. Los permisos se establecen en la unin de los permisos de todas las entradas que estn en la clase de grupo, por lo que la entrada de la mscara no esconde ningn permiso. La entrada mscara ahora se asigna a los permisos de grupo clase. La salida de ls cambios como se muestra a continuacin.dir $ ls-dl drwxrwx --- + ... suse agruen ... dir

Un carcter ``+'' adicional aparece despus de los permisos de todos los archivos que han cursado ACL. Esto parece un cambio extrao, pero en realidad POSIX.1 asigna esta posicin de carcter opcional a la bandera mtodo de acceso alternativo, que pasa por defecto a un carcter de espacio en caso de ausencia de mtodos de acceso alternativos estn en uso. Los permisos de los permisos de grupo clase incluyen el acceso de escritura. Tradicionalmente bits como permiso de archivo que indican el acceso de escritura para el grupo propietario. Con ACL, los permisos efectivos del grupo propietario se define como la interseccin de los permisos del grupo propietario de las entradas y la mscara. Los permisos efectivos del grupo propietario en el ejemplo an rx,los mismos permisos que antes de crear entradas adicionales ACL con setfacl. Los permisos de clase en grupo puede ser modificado usando el comando setfacl o chmod. Si no existe la mscara de entrada, chmod modifica los permisos del grupo propietario de la entrada como lo hace tradicionalmente. El siguiente ejemplo elimina el acceso de escritura de la clase de grupo y los controles lo que pasa.Dir $ chmod gw dir $ ls-dl drwxr-x --- + ... suse agruen ... $ Getfacl - dir omitir-cabecera usuario:: rwx usuario: joe: rwx # efectiva: rx Grupo:: rx mscara:: rx dir

otros ::---

Como se muestra, si una entrada ACL contiene los permisos que se desactivan por la entrada de la mscara, getfacl agrega un comentario que muestra el conjunto efectivo de permisos concedidos por la entrada. Haba a la entrada del grupo propietario haba acceso de escritura, no habra sido un comentario similar para esa entrada. Ahora ver lo que sucede si el acceso a escritura se da a la clase de grupo de nuevo.$ Chmod g + w dir dir $ ls-dl drwxrwx --- + ... suse agruen ... $ Getfacl - dir omitir-cabecera usuario:: rwx usuario: joe: rwx Grupo:: rx mscara:: rwx otros ::--dir

Despus de aadir el permiso de escritura en la clase de grupo, la ACL se definen los mismos permisos que antes de tomar el permiso de distancia. El comando chmod tiene un efecto destructivo sobre los permisos de acceso. Esta preservacin de los permisos es una caracterstica importante de las ACL POSIX.1e.

ACL por defecto EjemploEn el siguiente ejemplo, aadimos una ACL por defecto en el directorio. Entonces comprobamos lo que muestra getfacl.$ Setfacl-d-m grupo: toolies: dir rx $ Getfacl - dir omitir-cabecera usuario:: rwx usuario: joe: rwx Grupo:: rx mscara:: rwx otros ::--por defecto: Usuario:: rwx por defecto: grupo:: rx por defecto: grupo: toolies: rx por defecto: mscara:: rx por defecto: otros ::---

Tras el acceso ACL, la ACL por defecto se imprime con cada entrada con el prefijo `` por defecto:''. Este formato de salida es una extensin de POSIX.1e que se encuentra en Solaris y Linux. Una aplicacin estricta de 1003.2c POSIX slo mostrar el resultado de la ACL de acceso. La ACL por defecto se muestran con la opcin-d para getfacl. Slo hemos especificado una entrada de ACL para el grupo toolies en el comando setfacl. Las otras entradas necesarias para una ACL completa automticamente han sido copiados de la ACL de acceso a la ACL por defecto. Esta es una extensin especfica de Linux, en otros sistemas de todas las entradas puede ser necesario especificar explcitamente.

La ACL no contiene ninguna entrada de Joe, as que Joe no tendrn acceso (excepto posiblemente a travs de la pertenencia a grupos o los permisos de otra clase). Un subdirectorio hereda la ACL que se muestra a continuacin. A menos que se especifique lo contrario, el comando mkdir utiliza un valor de 0777 como el parmetro de modo que la llamada al sistema mkdir, que se utiliza para crear el nuevo directorio. Obsrvese que tanto el acceso y la ACL por defecto contienen las mismas entradas.$ Mkdir dir / subdir $ Getfacl - omitir encabezado dir / subdir usuario:: rwx Grupo:: rx Grupo: toolies: rx mscara:: rx otros ::--por defecto: Usuario:: rwx por defecto: grupo:: rx por defecto: grupo: toolies: rx por defecto: mscara:: rx por defecto: otros ::---

Los archivos creados en el interior dir heredan sus permisos como se muestra a continuacin. El comando touch pasa un valor medio de 0666 para el ncleo para crear el archivo. Todos los permisos no incluidos en el parmetro modo se eliminan las entradas ACL correspondientes. Lo mismo ha sucedido en el ejemplo anterior, pero no hubo ningn efecto apreciable porque el valor de 0777 utilizado para el parmetro de modo representa un conjunto completo de permisos.$ Touch dir / archivo $ Ls-l dir / archivo -Rw-r ----- + ... suse agruen ... dir / archivo $ Getfacl - omitir encabezado dir / archivo usuario:: rwGrupo:: rx # efectiva: r Grupo: toolies: rx # efectiva: r mscara:: r otros ::---

Sin permisos se han quitado de las entradas ACL en la clase de grupo, sino que no son ms que mscaras y, por tanto hizo ineficaz. Esto garantiza que las herramientas tradicionales, como los compiladores interactuar bien con ACL. Pueden crear archivos con permisos restringidos y marcar los archivos ejecutables ms tarde. El mecanismo de la mscara har que el derecho de los usuarios y grupos para acabar con los permisos de espera.

Atributos extendidosEn esta seccin comenzamos detallando la aplicacin de ACL en Linux. ACL son piezas de informacin de longitud variable que se asocian con los objetos del sistema de archivos. estrategias dedicadas para ACL almacenar en sistemas de archivos pueden ser elaborados, como Solaris hace en el sistema

de archivos UFS [ 13 ]. Cada inodo en un sistema de archivos UFS tiene un campo denominado i_shadow. Si un nodo-i tiene una ACL, este yacimiento apunta a un inodo sombra.En el sistema de archivos, inodos sombra se utilizan como archivos normales. Cada tiendas inodo la sombra de un ligamento cruzado anterior en sus bloques de datos. archivos mltiples con la misma ACL puede sealar el inodo misma sombra. Debido a otro kernel y las extensiones de espacio de usuario, adems de beneficiarse ACL de ser capaz de asociar piezas de informacin con los archivos, Linux y la mayora de UNIX como los sistemas operativos implementar un mecanismo ms general convocada atributos extendidos (EA). En estos sistemas, las ACL se implementan como AE. Los atributos extendidos son pares de nombre y valor asociado permanentemente con los objetos del sistema de archivos, similar a las variables de entorno de un proceso. El sistema de EA pide utilizar como interfaz entre el espacio de usuario y la copia del kernel los nombres de atributos y valores entre el usuario y los espacios de direcciones del ncleo. El atributo 'Linux (5) en el manual contiene una descripcin ms completa de EA que se encuentran en Linux. Un artculo de Robert Watson discutir infraestructura de apoyo para las extensiones de seguridad en FreeBSD contiene una comparacin de las diferentes implementaciones de EA en diferentes sistemas [ 25 ]. Otros sistemas operativos, como Sun Solaris, MacOS de Apple y Microsoft Windows, permite mltiples flujos (o tenedores) de informacin que se asocia con un solo archivo. Estas corrientes de apoyo de la semntica de archivos habituales. Despus de obtener un identificador en la secuencia, es posible acceder a los arroyos "contenido mediante las operaciones ordinarias de archivo como de lectura y escritura. Confusin, en Solaris estas corrientes se les llama atributos extendidos tambin. La EA en Linux y otros sistemas operativos tipo UNIX no tienen nada que ver con estas corrientes. La interfaz de EA ms limitada ofrece varias ventajas. Son ms fciles de aplicar, las operaciones de EA son inherentemente atmica, y la interfaz de aptridas no sufre de gastos ocasionados por la obtencin y liberacin de identificadores de archivo. La eficiencia es importante para los objetos de acceso frecuente como ACL. A nivel de sistema de archivos, el enfoque claro y directo para poner en prctica EA es crear un directorio adicional para cada objeto del sistema de archivo que tiene EA y crear un archivo para cada atributo extendido que tiene el nombre del atributo y contiene el valor del atributo. Porque en la mayora de los sistemas de archivo de la asignacin de un directorio adicional, ms uno o ms archivos requiere de varios bloques de disco, una aplicacin sencilla que consumen mucho espacio, y no funcionan muy bien debido al tiempo necesario para acceder a todos estos bloques de disco. Por lo tanto, la mayora de los sistemas de archivos utilizan mecanismos diferentes para el almacenamiento de EA.

EXT2 Y EXT3

Como se describe en las fuentes del kernel de Linux, cada nodo-i tiene un campo que se llama i_file_acl por razones histricas. Si este campo no es cero, contiene el nmero del bloque de sistema de archivos en los que la AE asociados con este inodo se almacenan. Este bloque contiene los nombres y valores de todos los EA relacionados con el inodo. Todas las reas censales de un inodo debe caber en el mismo bloque de EA. Para mejorar la eficiencia, inodos mltiples con juegos idnticos de EA puede apuntar al mismo bloque de EA. El nmero de nodos se refiere a un bloque de EA son seguidos por un recuento de referencia en el bloque de EA. intercambio de EA bloque es transparente para el usuario: Ext3 mantiene una lista de EFP se ha accedido recientemente bloques de EA y una tabla que tiene dos ndices (en ejecucin como las tablas hash de doble listas enlazadas). Un ndice por nmero de bloque. La otra es por una suma de comprobacin del contenido del bloque. Los bloques que contienen los mismos datos con los que ser un nuevo inodo asociado se reutilizan hasta que el recuento del bloque de referencia llega a un lmite mximo de 1024. Esto limita el dao que un fallo en el disco solo bloque puede causar. Cuando un nodo-i se refiere a un bloque de EA y EA compartida inodo que se cambian, una copia por escritura mecanismo se utiliza, a menos que otro bloque de cach EA ya contiene el mismo conjunto de atributos, en cuyo caso se utiliza ese bloque. La implementacin actual requiere que todos los EA de un nodo-i para que quepa en un bloque nico disco, que es 1, 2, o 4 KiB. Esto tambin determina el tamao mximo de los atributos individuales. Si los juegos de EA tienden a ser nico entre los inodos, sin compartir es posible y el tiempo dedicado a la comprobacin de compartir potencial se desperdicia. Si cada nodo-i tiene un conjunto nico de EA, cada uno de estos conjuntos se pueden almacenar en un bloque de disco independiente, que puede conducir a una gran cantidad de espacio de holgura. El caso extremo son las aplicaciones que necesitan almacenar EA nico para cada nodoi. Afortunadamente para muchas cargas de trabajo comn, el mecanismo de reparto de EA es muy eficaz. diseos alternativos con menos limitaciones se han propuesto [ 5 ], pero parece que no son fciles de aplicar en la prctica. No hay alternativas al rgimen actual existen hasta ahora.JFS

JFS almacena todos los EA de un inodo en un rango consecutivo de bloques en el sistema de archivos (es decir, en un punto) [ 3 ]. El nombre del atributo extendido y pares de valores se almacenan en forma consecutiva en este sentido. Si la AE todo son lo suficientemente pequeos, se almacenan por completo en el inodo a la que pertenecen.

JFS no implementa un mecanismo de reparto de EA. No tiene la limitacin de un disco de bloque de Ext2 y Ext3. El tamao de los atributos individuales est limitado a 64 KB.XFS

De los sistemas de archivos soportados en Linux, XFS utiliza el esquema ms elaborado para almacenar los atributos extendidos [ 1 ]. Los pequeos conjuntos de EA se almacenan directamente en los inodos, conjuntos de tamao mediano se almacenan en bloques de hojas de rboles B +, y grandes conjuntos de EA se almacenan en su totalidad los rboles B +. Esto se traduce en caractersticas de rendimiento similares a los directorios de XFS: aunque rara vez se necesita, una gran cantidad de EA se puede almacenar de manera eficiente. XFS tiene un tamao de inodo configurable que se determina en el sistema de archivos crear tiempo. El tamao mnimo es de 256 bytes, que es la opcin por defecto. El tamao mximo es la mitad del tamao del archivo de bloque del sistema. En el caso mnimo, los inodes son demasiado pequeos para contener ACL, por lo que sern almacenados externamente. Si el tamao de inodo es mayor, ACL se encaja directamente en el inodo. Desde inodos y su ACL son utilizadas ms frecuentemente en un corto perodo de tiempo, esto se traduce en los controles de acceso ms rpido, pero tambin pierde ms espacio en disco. XFS no tiene un mecanismo de reparto de atributos. El tamao de los atributos individuales est limitado a 64 KB.REISERFS

ReiserFS apoya la fusin de la cola de archivos, lo que significa que varios archivos pueden compartir el mismo bloque de disco para almacenar sus datos. Esto hace que el sistema de archivos muy eficiente para muchos archivos pequeos. Un posible inconveniente es que la cola de la fusin puede consumir una cantidad notable de tiempo de CPU. Desde ReiserFS es tan bueno en el manejo de archivos pequeos, EA puede utilizar directamente este mecanismo. Para cada archivo que tiene EA, un directorio con un nombre derivado de un identificador nico inodo se crea dentro de un directorio especial. El directorio especial es por lo general oculta del espacio de nombres del sistema de archivos. Dentro del directorio especfico de inodos, cada EA se almacena como un archivo independiente. El nombre del archivo es igual al nombre del atributo. El contenido del archivo es el valor del atributo. ReiserFS no implementa un mecanismo de intercambio de atributo, pero tal extensin, posiblemente, se llevar a cabo en el futuro. Compartir incluso podran aplicarse en una base per-atributo, por lo que el resultado sera una

solucin altamente eficiente y flexible. El tamao de los atributos individuales est limitado a 64 KB.

ACL ImplementacionesUna decisin de diseo interesante es cmo ACL se debe pasar entre el espacio de usuario y el kernel, y dentro del ncleo, entre el sistema de archivos virtual (VFS) y la capa de archivos de bajo nivel del sistema. FreeBSD, Solaris, Irix, HP-UX y todos han separado del sistema de ACL llamadas [ 21 , 9 , 23 , 17 ]. Linux no tiene llamadas ACL del sistema. En cambio, las ACL se pasan entre el ncleo y el espacio de usuario como AE. Esto reduce el nmero de interfaces del sistema, pero con el mismo nmero de operaciones de final. Mientras que las llamadas al sistema ACL proporcionan una interfaz de sistema ms explcita, la interfaz de EA es ms fcil de adaptarse a las necesidades futuras, tales como identificadores no numrico para usuarios y grupos en las entradas ACL. La justificacin del uso de sistemas separados ACL llamadas en FreeBSD es que algunos sistemas de archivos AE apoyo, pero no ACL, y algunos sistemas de archivos ACL apoyo, pero no EA, por lo que EA se tratan como puro datos binarios. EA y ACL slo son relacionados dentro de un sistema de archivos. [ 24 , 26 ]. El fundamento para el diseo de Linux era proporcionar acceso a todos los meta datos pertinentes a un objeto de sistema de archivos a travs de la misma interfaz. Las diferentes clases de atributos que se reconocen por su nombre estn reservados para los objetos del sistema, tales como ACL. Los nombres de atributo''`` system.posix_acl_access y system.posix_acl_default ``''se utilizan para el acceso y la ACL por defecto de un archivo, respectivamente. Los valores de los atributos de ACL estn en formato cannico, binario de la arquitectura. Los sistemas de archivos que no implementan ACL pero aplicar EA, o los que implementan ACL como algo distinto de EA, la necesidad de reconocer los nombres de atributos relevantes. Si bien es posible manipular ACL directamente como AE, a nivel de aplicacin de este por lo general no se hace: desde las llamadas al sistema de EA son especficas de Linux, las aplicaciones no sera porttil. Otros sistemas de apoyo a mecanismos similares de EA, pero con diferentes interfaces del sistema de llamada. Las aplicaciones que desea utilizar ACL POSIX.1 de una manera porttil se espera que utilicen la biblioteca libacl, que implementa la especfica de las funciones de ACL del proyecto de POSIX.1e 17. El acceso ACL para un objeto de sistema de archivos se tiene acceso a todas las decisiones que implica el acceso a ese objeto. control de acceso se realiza en todo el camino desde la raz espacio de nombres al archivo en cuestin. Es importante que los controles de acceso ACL son eficientes. Para evitar mirar

hacia arriba con frecuencia los atributos de ACL y su conversin de la representacin atributo independiente de la mquina a una representacin especfica de la mquina, el Ext2, Ext3, JFS, ReiserFS y cach implementaciones de las representaciones ACL especficas de la mquina. Esto se hace, adems de los mecanismos normales de almacenamiento en cach de archivos del sistema, que utilizar la cach de pginas, la cach del bfer, o ambos. XFS no utiliza esta capa adicional de almacenamiento en cach. La mayora de los sistemas tipo UNIX que soporte ACL limitar el nmero de entradas de la LCA permite a un nmero razonable. La Tabla 3 muestra los lmites en Linux.Entradas ACL: Cuadro Nmero mximo de admitidos Sistema de archivos XFS Ext2, Ext3 ReiserFS, JFS Max. de las entradas 25 32 8191

ACL con un elevado nmero de entradas de la LCA tienden a ser ms difcil de manejar. Ms de un puado de entradas ACL son por lo general un indicador de mal diseo de la aplicacin. En la mayora de estos casos, tiene ms sentido hacer un mejor uso de los grupos en lugar de distensin ACL. Las implementaciones de ReiserFS y JFS definir ningn lmite en el nmero de entradas de la LCA, por lo que slo es un lmite impuesto por el tamao mximo de los valores de EA. El actual lmite de tamao de EA es de 64 KiB, o 8191 entradas de LCA, que es demasiado alto para ACL en la prctica: adems de ser poco prctico para trabajar, el tiempo que tomara para comprobar el acceso de tal ACL grandes pueden ser prohibitivos.

CompatibilidadUn aspecto importante de la introduccin de las nuevas caractersticas del sistema de archivos es cmo los sistemas se actualizan, y cmo los sistemas que no son compatibles con las nuevas caractersticas se ven afectadas. Formatos de archivo del sistema evolucionan lentamente. Los sistemas de archivos se espera que continuar trabajando con las versiones anteriores del kernel. En algunas situaciones, como en entornos de arranque

mltiple o cuando se arranca desde un sistema de rescate, puede ser necesaria o preferible utilizar un kernel que no tiene el apoyo de EA. Todos los sistemas de archivos que soporte ACL en Linux estn o intrnsecamente consciente de EA, o mejorados estn para apoyar a EA de forma automtica, sin intervencin del usuario. Dependiendo del sistema de archivos, esto es bien hecho durante el montaje o la primera vez que el uso de atributos extendidos. En todos los sistemas de archivos mencionados en este documento, utilizando un ncleo que no es compatible con EA en un sistema de archivos con EA, la EA ser ignorado. En ReiserFS, granos de EA-consciente activamente ocultar el directorio del sistema que contiene la AE, por lo que en un ncleo de EA que no reconocen este directorio se hace visible. Sigue siendo protegida de los usuarios normales a travs de los permisos de archivos. Trabajar con sistemas de archivos de EA con los ncleos de EA que no reconocen todava dar lugar a incoherencias cuando se eliminan archivos que tienen EA. En ese caso, la AE no se eliminan y una prdida de espacio en disco resultado. Al menos en Ext2 y Ext3, estas inconsistencias se pueden limpiar ms tarde ejecutando el corrector del sistema de archivos. ncleos ACL-consciente slo ver los bits de archivo tradicionales permiso y no ser capaz de verificar los permisos definidos en ACL. El algoritmo de herencia de ACL no funcionar.

EA y el rendimiento de ACLDesde ACL definir un ms sofisticado mecanismo de control de acceso discrecional, tienen una influencia en todas las decisiones de acceso para los objetos de sistema de archivos. Es interesante comparar el tiempo que se tarda en realizar una decisin de acceso con y sin ACL. Las mediciones se realizaron en una PC con SuSE Linux 8.2, con el SuSE 2.4.20 del kernel. La mquina tiene un procesador AMD Athlon frecuencia de reloj de 1,1 GHz y 512 MB de RAM. El disco utilizado fue un IBM de 30 GB Ultra ATA 100 con disco duro de 7200 RPM, un tiempo medio de bsqueda de 9,8 ms, y 2 MB de cach en el disco. El Ext2, Ext3, ReiserFS, JFS y los sistemas de archivos creados con las opciones por defecto en una particin de 8 GiB. En XFS, comparar EA que se almacenan en los inodos y EA que se almacenan en el exterior, los sistemas de archivos con un tamao de inodos de 256 bytes y 512 bytes se utilizaron. Estos sistemas de archivos estn etiquetados XFS XFS-256 y 512, respectivamente. Tabla 4 compara los tiempos necesarios para la comprobacin de acceso inicial a un archivo con y sin una ACL tras reiniciar el sistema. Para excluir el tiempo de carga de archivos de inodo en la cach, una llamada al sistema de estadsticas se realiz antes de la comprobacin de acceso. El tiempo necesario para que la llamada al sistema de estadsticas no se muestra. El primer acceso a la ACL de acceso de un archivo puede requerir uno o ms

accesos a disco, que son varios rdenes de magnitud ms lento que el acceso a la cach. Los tiempos reales de estos accesos a disco adoptar varan mucho depender de la velocidad del disco y en la ubicacin relativa de los bloques de disco que se tiene acceso. La funcin utilizada para medir el tiempo tiene una resolucin de microsegundos. En el caso de ACL, el archivo que est protegido tiene un acceso ACL cinco de entrada.Tabla: microsegundos para un primer acceso a un archivo despus de reiniciar elsistema, con y sin ACL Sin ACL Ext2 Ext3 ReiserF S XFS256 XFS512 JFS 9 10 9 Con ACL 1743 3804 6165

14

7531

14 14 13 13

XFS con 512 bytes (o ms) inodos y JFS guardar la ACL directamente en los inodos. Por lo tanto, no hay accesos a disco se necesitan para la recuperacin de la ACL. Despus de la primera repeticin, toda la informacin est totalmente en cach. Figuras 2 4 mostrar el resultado de micro-puntos de referencia de las operaciones bsicas en este estado. Cada ensayo se repite la misma operacin muchas veces y media el tiempo total por el nmero de repeticiones. En todas las configuraciones excepto XFS-256 con ACL, el tiempo por comprobacin de acceso se reduce a alrededor de microsegundos, segn las mediciones ms a la izquierda en las Figuras 3 y 4 muestran. Figura 2 compara la velocidad de las llamadas al sistema diferentes. La llamada al sistema getpid se incluye para mostrar el resultado de la sobrecarga de conmutacin entre el usuario y los espacios de direcciones del ncleo. El

comando ls-l indica en su salida si un archivo tiene una ACL extendida. Internamente, se utiliza la funcin de la biblioteca acl_extended_file libacl. Esta funcin es casi tan rpido como la llamada al sistema de estadsticas, que ls-l tambin pide para cada archivo, por lo que la sobrecarga adicional es pequea. En comparacin, la medicin acl_get_file muestra el tiempo que se tarda en recuperar una ACL cinco de entrada.

Figura: Sistema de distintas convocatorias y Funciones de la biblioteca

La Figura 3 muestra el tiempo necesario para que una llamada al sistema de acceso, en funcin del nmero de niveles de directorios en el argumento de ruta. Figura 4 muestra el rendimiento de la misma operacin con una entrada de acceso ACL-cinco en cada directorio. sobrecarga de XFS para la conversin de la ACL de su representacin de EA a sus resultados representacin en memoria de una diferencia notable, en particular, con 256 inodos bytes.

Figura: El acceso al sistema de llamadas sin ACL

Figura: El acceso de llamadas al sistema con ACL

Tablas 5 y 6 muestran la sobrecarga que tienen lugar cuando se copian archivos de sistema de archivos de una a otra. Todos los archivos que se copian han ACL, pero no EA adicionales. Figura 5 muestra la distribucin de tamao de los archivos en los conjuntos de datos de la muestra. Las pruebas muestran que el tiempo que se inicie el comando cp para el retorno del comando de sincronizacin, que se iniciar inmediatamente despus del comando cp. El comando de sincronizacin asegura que todos los archivos se escriben inmediatamente. La primera serie utiliza una versin de PC que no es compatible con EA o ACL. La segunda serie utiliza una versin de PC que soporta tanto EAs y ACLs. En los dos puntos de referencia, el archivo de origen el tipo de sistema se mantiene constante, mientras que el archivo de destino el tipo de sistema se cambia. El tamao de la muestra para el punto de referencia en la Tabla 5 es lo suficientemente pequeo como para todos los archivos para caber en la memoria principal. El tiempo para la primera lectura de los datos en la memoria no est incluido en los resultados. Estas pruebas se repitieron cinco veces. Los resultados muestran la media y la desviacin estndar de los resultados. El tamao de la muestra para el valor de referencia se muestra en la Tabla 6 es ms grande que cualquiera de la memoria principal o en las revistas del sistema de archivos. Estas pruebas fueron ejecutados una sola vez.Tabla: segundos para copiar archivos de la memoria de un sistema de archivos(11.351 mil archivos, directorios de 608, tamao de archivo total = 137 MiB)

Archivo sistema de

Sin AE

Con

Gastos generales (%)

o ACL

ACL

Ext2

18. 3

0. 18. 2 8

0. 2

3

Ext3

22. 0

2. 22. 4 7

0. 5

3

ReiserFS

9.0

0. 12. 1 8

0. 1

42

XFS-256

19. 0

0. 34. 2 1

0. 2

80

XFS-512

20. 1

0. 21. 4 4

0. 2

7

JFS

38. 2

0. 36. 6 5

0. 2

4

Tabla: segundos para copiar archivos entre sistemas de archivos (96.183 archivos,directorios de 6323, el tamao total del archivo = 2,8 GiB) Archivo sistema de Sin Co AE n o AC ACL L 57 8 Gastos generales (%)

Ext2

595

3

Ext3

613

62 3

2

ReiserFS

518

53 8

4

XFS-256

547

64 1

17

XFS-512

549

56 6

3

JFS

654

59 0

11

Figura: Distribucin de tamao de los archivos de muestras de loscuadros 5 y 6

Tenga en cuenta que tanto los puntos de referencia utilizar ACL en exceso, que es el peor de los casos. Los gastos generales para cargas de trabajo real debe ser mucho menor. Se puede observar que la sobrecarga de ACL vara ampliamente entre los sistemas de archivos compatibles. La muestra diferencias ms cuando la carga de I / O es baja, y se hacen ms pequeos como el I / O se levanta la carga. Por ACL, el Ext2 y Ext3 implementaciones tienen pocos gastos indirectos. EA ReiserFS tienen una sobrecarga relativamente alto. Esto puede mejorar si se lleva a cabo el intercambio de atributos. Para XFS, aumentando el tamao de inodo para que las ACL se pueden almacenar directamente en inodos hace una gran diferencia. No est claro por qu JFS parece ser ms rpida si la copia que cuando ACL ACL copia no.

NFS y ACLCompleto soporte de ACL a travs de NFS requiere dos cosas: En primer lugar, un mecanismo para que todas las decisiones de acceso se realizan de una manera que honre a la ACL. En segundo lugar, las extensiones para el protocolo NFS para la manipulacin de las ACL en el control remoto sistemas de ficheros montados. El protocolo NFS lleva a cabo el almacenamiento en cach de cliente para mejorar la eficiencia. En la versin 2 del protocolo, las decisiones sobre quin recibe el acceso de lectura a los datos almacenados localmente en cach se realizan en el cliente. Estas decisiones se hacen bajo el supuesto de que el archivo de los permisos de modo de bits y los identificadores del propietario y grupo propietario son suficientes para hacer eso. Este supuesto es, obviamente, mal si un rgimen de autorizacin extendida como POSIX ACL se utiliza en el servidor. Dado que los clientes NFSv2 realizar algunas decisiones de acceso local, que incorrectamente conceder acceso de lectura a los contenidos de archivos y directorios almacenados en cach en el cliente para los usuarios que es un miembro del grupo propietario en dos casos. En primer lugar, si los permisos de clase de grupo incluyen el acceso de lectura, pero el grupo propietario no tiene acceso de lectura. En segundo lugar, si no el grupo propietario tiene acceso de lectura, pero una entrada de usuario el nombre de ese usuario que existe no permite el acceso de lectura. Ambas situaciones son poco comunes.Existen soluciones que reduzcan los permisos en el servidor para que los clientes slo ven un subconjunto seguro de los permisos reales [ 10 , 7 ]. No hay anomalas existen para los usuarios que no es un miembro del grupo propietario. Hay dos maneras de resolver este problema. Uno de ellos es extender el algoritmo de control de acceso utilizado en el cliente. La otra es la de delegar decisiones de acceso al servidor de cach y, posiblemente, las decisiones por un periodo de tiempo definido en el cliente. La primera solucin probablemente sera mejor escala a un gran nmero de lectores en el cliente, siempre y cuando el servidor y todos los clientes pueden ponerse de acuerdo sobre el uso de algoritmos de comprobacin de acceso. Por desgracia, este enfoque se desmorona tan pronto como servidores de aplicacin de diferentes esquemas de permiso. La versin 3 del protocolo NFS tanto, define una nueva llamada a procedimiento remoto (RPC) de llamada ACCESS para delegar decisiones de acceso al servidor. Este RPC es similar a la llamada al sistema de acceso. clientes NFSv3 se espera utilizar esta RPC para determinar a quin conceder el acceso a los contenidos almacenados en cach. El protocolo NFSv3 por desgracia no define los mecanismos para la transferencia de ACL. Como consecuencia de ello, diferentes fabricantes han implementado extensiones propietarias protocolo que son incompatibles entre s. Solaris implementa una extensin del protocolo NFSv3 llamada NFS ACL

que soporta ACL solamente. Irix implementa un protocolo ms general que admite EA y pasa ACL como AE especial. NFSv4 define la estructura y la semntica de su propio tipo de ACL, junto con RPC para transferirlos entre clientes y servidores. ACL de NFSv4 son similares a Microsoft Windows ACL [ 14 ].Desafortunadamente, los diseadores de NFSv4 en su mayora han ignorado la existencia de ACLs POSIX, por lo que NFSv4 ACL no son compatibles con POSIX ACL. Marius Aamodt Eriksen describe una va asignacin uno entre POSIX ACL y ACL de NFSv4 [ 6 ], pero esta asignacin no es prctico. Uno de los conceptos centrales en POSIX ACL, que es necesaria para garantizar la compatibilidad con el legado de POSIX.1 aplicaciones, es la entrada de la mascarilla. El modelo de NFSv4 ACL puede ser prorrogado por el concepto de mscara. A pesar de este gran medida mejorar la interoperabilidad con POSIX ACL, las propuestas para extender la especificacin NFSv4 hasta ahora han sido rechazadas.

apoyo NFSv3 parcial se ha aadido en la serie 2.2 del ncleo Linux. El RPC ACCESO sido aadido a la demonio de NFS en la versin del kernel 2.2.18, pero el cliente NFS slo utiliza correctamente la RPC de acceso en el ncleo de la serie 2.5. Un parche para los mayores ncleos existe desde la versin 2.4.19 del ncleo, que se incluye en los productos SuSE y UnitedLinux. Debido a que la RPC ACCESO puede conducir a la notable sobrecarga de la red, incluso en sistemas de archivos que se sabe que no incluye ninguna ACL, el NFSv3 cliente de Linux permite montar sistemas de archivos con la opcin de montaje noacl. A continuacin, el cliente NFS uso ni el acceso ni getacl RPC o RPC setacl. Para asegurarse de que no ACL se pueden establecer en el servidor, el Ext2, Ext3, JFS, ReiserFS y sistemas de archivos puede ser montado en el servidor sin soporte ACL por omisin de la opcin de montaje acl. Desde marzo 3, 2003, una implementacin del protocolo NFS de dom ACL para Linux (que tambin se incluye en SuSE Linux 8.2) est disponible en http://acl.bestbits.at/ , con permiso amable de Sun para su uso. El protocolo NFS ACL fue elegido porque es simple y compatible con POSIX 1003.1e proyecto de 17 ACL bastante bien. ACL Solaris se basan en un proyecto anterior de POSIX 1003.1e, por lo que su manejo de la mscara de entrada de ACL es un poco diferente que en el proyecto de 17 para ACL con slo cuatro entradas ACL. Este es un caso de esquina que se produce rara vez, por lo que las diferencias semnticas no puede ser notable.

Samba y ACLMicrosoft Windows es compatible con ACL en su sistema de archivos NTFS, y en su Common Internet File System (CIFS) [ 20 ], que anteriormente ha sido

conocida como Server Message Block (SMB).CIFS se utiliza para ofrecer servicios de archivos e impresin a travs de una red. Samba es una implementacin Open Source de CIFS. Se utiliza para ofrecer archivos UNIX y servicios de impresin para los usuarios de Windows. Samba permite POSIX ACL para ser manipulada de Windows. Esta caracterstica aade una nueva calidad de la interoperabilidad entre UNIX y Windows. El modelo de ACL de Windows difiere del modelo POSIX ACL en un nmero de maneras, por lo que no es posible ofrecer la integracin perfecta del todo. Las diferencias ms significativas entre estos dos tipos de ACL son:

ACL de Windows de apoyo sobre los permisos de diez diferentes para cada entrada en una ACL, incluyendo cosas tales como aadir y borrar, cambiar permisos, tomar posesin y la propiedad cambia. Las implementaciones actuales de POSIX.1 ACL slo admiten leer, escribir y ejecutar permisos. En el algoritmo de verificacin POSIX permiso, la entrada de ACL ms significativos define los permisos se concede un proceso, los permisos de forma ms detallada se calcul sumando ms de cerca se pongan en venta las entradas ACL cuando sea necesario. En el modelo de ligamento cruzado anterior de Windows, los permisos son acumulativos, por lo que los permisos que de otro modo se otorgara slo puede ser restringido por negar entradas ACL. ACL POSIX no son compatibles con las entradas ACL que niegan los permisos. Un usuario se puede negar permisos a crear una entrada de ACL que especficamente coincide con el usuario. ACL de Windows han tenido un modelo de herencia que era similar al modelo POSIX ACL. Puesto que Windows 2000, Microsoft utiliza un modelo de herencia dinmica que permite que los permisos se propaguen por la jerarqua de directorios cuando los permisos de los directorios padre se modifican. POSIX ACL son heredadas en el archivo de crear nica vez. En el modelo POSIX ACL, ACL de acceso y por defecto son conceptos ortogonales. En el modelo de ligamento cruzado anterior de Windows, varias banderas diferentes en cada control de entrada de ACL cundo y cmo esta entrada es heredado por los objetos contenedor y no contenedor.

ACL de Windows tienen conceptos diferentes de cmo se definen los permisos para el dueo del archivo y grupo propietario. El concepto de grupo propietario slo se ha aadido con Windows 2000.Esto conduce a resultados distintos si los cambios de propiedad de los archivos.

ACL POSIX tienen entradas para el propietario y el grupo propietario tanto en el acceso ACL y en la ACL por defecto. En el momento de la comprobacin de acceso a un objeto, estas entradas se asocian con el propietario actual y el grupo propietario de ese objeto. ACL de Windows admiten dos grupos pseudo llamado Creador propietario y creador del grupo que tienen un propsito similar para los permisos heredables, pero no permita que estos grupos pseudo las entradas que definen el acceso. Cuando un objeto hereda los permisos, las entradas abstractas se convierten en las entradas para un usuario especfico y de grupo. A pesar de la falta de coincidencia semntica entre estos dos sistemas ACL, ACL POSIX se presentan en el editor de ACL de Windows cuadro de dilogo para que se asemejan a las ACL de Windows nativo muy de cerca. usuarios ocasionales no es probable que darse cuenta de las diferencias. administradores con experiencia, sin embargo ser capaz de detectar algunas diferencias. El mapeo entre POSIX y ACL de Windows se describe aqu se encuentra en esta forma en el SuSE y los productos UnitedLinux, mientras que la versin oficial de Samba todava no ha integrado todas las mejoras recientemente:

Los permisos en el acceso POSIX ACL se asignan a los permisos de acceso de Windows. Los permisos por defecto en el POSIX ACL se asignan a los permisos de Windows heredables. POSIX ACL mnima consistir en tres entradas ACL que define los permisos para el propietario, grupo propietario, entre otros. Estas entradas son obligatorios. ACL de Windows puede contener cualquier nmero de entradas incluyendo el cero. Si una de las entradas POSIX ACL no contiene los permisos y la omisin de la entrada no da lugar a una prdida de informacin, la entrada est oculto a los clientes de Windows. Si un cliente Windows establece una ACL en la que faltan las entradas necesarias, los permisos de entrada que se borran en el correspondiente ACL POSIX. La entrada de la mscara en POSIX ACL no tiene correspondencia en las ACL de Windows. Si los permisos

en un ACL POSIX son ineficaces porque son enmascarados y una lista ACL se modifica a travs de CIFS, los permisos de enmascarados se quitan de la ACL.

Debido a las ACL de Windows slo admiten el Creador propietario y creador grupos pseudo Grupo de los permisos heredables, propietario y dueo de las entradas de grupo en una ACL por defecto se asignan a los grupos de pseudo. Por ACL de acceso, estas entradas se asignan a las entradas con nombre para el propietario actual y el grupo propietario actual (por ejemplo, la ACL de entrada `` POSIX u::''rw de un fichero propiedad de Joe es tratado como `` u: joe: ''rw). Si un acceso ACL contiene el nombre de las entradas ACL para el propietario o grupo propietario (por ejemplo, si uno de los archivos de Joe tambin tiene una u ``: joe: ... tus''), los permisos se definen en las entradas no son efectivos a menos que el archivo cambios de propiedad, de las entradas llamado as por ejemplo se pasan por alto. Cuando una ACL se establece por Samba que contiene Creador propietario o entradas Creador del grupo, estas entradas se les da prioridad sobre las entradas lleva el nombre del actual propietario y grupo propietario, respectivamente.

POSIX ACL de acceso y las entradas ACL por defecto que definen los mismos permisos que se asignan a una entrada de ACL de Windows que se marca como la definicin de acceso y permisos heredables.

Copia de seguridad y restauracinUn aspecto importante, pero pasa por alto con facilidad de la introduccin de nuevas caractersticas como EA y ACL es copia de seguridad. herramientas estndar como GNU tar y cpio GNU no incluyen EA o soporte ACL. El ustar y el archivo en formato cpio en que estas herramientas se basan permiten ciertas extensiones, pero no existen normas para el almacenamiento de EA o ACL se han definido an. La versin actual de POSIX.1 [ 11 ] define una nueva utilidad llamada pax, que significa para el intercambio de archivos porttiles. La utilidad pax admite tanto el formato de archivo ustar y cpio adems del formato de archivo de personas nuevas. Este nuevo formato se basa en ustar y es, en gran medida, compatible con ustar. Pax introduce un mecanismo llamado encabezados extendidos. encabezados extendido consisten en una lista de atributos muy similares a EA. Se utilizan para almacenar cosas que no se puede representar en los encabezados ustar, tales como marcas de tiempo inferiores a un segundo de resolucin o tamao de los archivos de 8 Gib o ms.

El formato de archivo de personas es un buen partido para el almacenamiento de EAs y ACLs. Dado que ni EA ni ACL son parte de cualquier estndar POSIX, ningn formato especfico para EA o ACL para su uso en los encabezados extendidos se ha definido. La especificacin deja espacio para los atributos especficos del proveedor etiquetados con el nombre del proveedor, as que aunque no pueda alcanzarse un acuerdo antes de la EA o en formato ACL a utilizar, las extensiones especficas del proveedor al menos pueden ser distinguidos e implementaciones pueden soportar ms de una extensin. Una de las ventajas del formato de personas es que la mayora de archivos de personas tambin se pueden restaurar con las implementaciones de alquitrn. Para alquitrn, encabezados extendidos parecen archivos de un tipo desconocido. La informacin almacenada en los encabezados extendidos se perdern, pero los archivos y directorios se pueden extraer correctamente. Esto no funcionar para los archivos de personas que contienen archivos de 8 GiB o ms de tamao, lo que es el tamao mximo de archivo en los archivos tar. Las siguientes soluciones existen para realizar copias de seguridad (y ms tarde la restauracin) EAs y ACLs:

Jrg Schilling ejecucin de personas y pidi estrellas alquitrn incluye soporte para ACL POSIX.1e y algunos otros. Los archivos resultantes son portables entre los sistemas que ejecutan diferentes versiones de POSIX ACL, incluyendo FreeBSD, Irix, HPUX, Compaq / HP Tru64, Linux, Solaris. Un parche de Linux que implementa el apoyo de EA en estrella tambin existe. Estrella est disponible en ftp://ftp.berlios.de/pub/star/ . En el sistema de archivos XFS, y xfsrestore utilidades xfsdump se puede utilizar. Sin embargo, el formato de copia de seguridad es el sistema de archivos especficos, por lo que este enfoque no es recomendable. Por ltimo, el getfattr y utilidades getfacl puede volcar ACL y EA a archivos de texto, que el setfattr y utilidades setfacl son capaces de restaurar. Esto funciona bastante bien para la restauracin de copias de seguridad completas, pero no es prctico para restaurar archivos individuales.

Solicitud de Apoyo a la ACLHoy en da, la mayora de las herramientas bsicas que se necesitan para operar un sistema con EA y ACL estn disponibles: no hay apoyo de EA y ACL en el archivo de servicios pblicos bsicos (ls, cp ymv), existen utilidades para la manipulacin de EAs y ACLs de la lnea de comandos, y hay soluciones para realizar copias de seguridad y restauracin de un sistema que utiliza esas caractersticas. Sin embargo, hay muchas aplicaciones que se carece de apoyo. Aunque para muchos de ellos esto es irrelevante, hay algunas clases de aplicaciones para las que esto conduce a problemas. Esto incluye los administradores de archivos, editores y herramientas de sistema de archivos de sincronizacin. Los administradores de archivos por lo general puede copiar y mover archivos y permitir que los permisos sean cambiados. ncleos de UNIX no tienen funciones para copiar archivos o para mover archivos a travs de los lmites del sistema de archivos. Por lo tanto, estas operaciones son ejecutadas por la lectura del archivo de origen y copia los datos en el archivo de destino. El ncleo no tiene manera de decir que las secuencias de las operaciones son copias de archivos o se mueve y que son otra cosa, por lo que no puede conservar EAs y ACLs de forma automtica. Esto significa que las aplicaciones deben tener cuidado de preservar EAs y ACLs a s mismos como sea necesario. Interfaces que permiten la manipulacin de los permisos por lo general permiten la manipulacin de la norma POSIX.1 permisos, pero no se sabe hasta ahora de que permiten la manipulacin de las ACL. Es muy probable que en el futuro previsible, soporte de ACL edicin no estar disponible sino con las utilidades de lnea de comandos. Algunos editores sufren el problema de la copia de archivos tambin. Hay dos formas de modificar un archivo de forma segura. Se trata de crear una copia del archivo original y luego modificar el archivo original. La otra es cambiar el nombre del archivo original y luego crear un nuevo archivo que incluye las modificaciones en el lugar del archivo original. Este ltimo es equivalente a copiar los archivos en cuanto a EA y ACL se refiere. La opcin de utilizar tambin tiene consecuencias adicionales para los archivos que son enlaces simblicos y archivos con un conteo mayor que uno. Emacs y vi, la mayora de los editores populares en como los sistemas UNIX, tanto puede ser configurado para usar uno u otro mtodo. Cuando la preservacin de los permisos, es importante que toda la informacin que se conserva como sea posible. Aunque esto parece obvio, correcta aplicacin de la presente no es trivial. Hay una serie de complicaciones que hacen que la operacin propenso a errores de implementacin. Esto es particularmente cierto si los archivos de origen y de destino residen en sistemas de archivos diferentes, slo uno de ellos con soporte ACL. Para aprovechar esta carga adicional de los programadores, la

versin actual de libacl incluye funciones para copiar EAs y ACLs entre archivos [ 8 ]. Tambin sera bueno tener el apoyo de EA y ACL en los servicios populares como scp y rsync. Por desgracia, las utilidades que la transferencia de archivos entre sistemas diferentes tienen un tiempo de incompatibilidades mucho ms difcil el manejo. Slo algunos sistemas UNIX como soporte de las funciones POSIX.1e ligamento cruzado anterior de la biblioteca y otros sistemas tienen sus propias interfaces del sistema operativo. Peor an, la semntica de la ACL con grandes diferencias entre los sistemas UNIX solo, por no hablar de los sistemas no UNIX. La semntica y las interfaces del sistema de EA por desgracia son diferentes entre los distintos sistemas tambin.

Conclusiones y trabajos futurosapoyo a la integracin de EA fue un paso importante que va a simplificar el desarrollo de varios tipos de aplicaciones, incluyendo las extensiones del sistema de seguridad de nivel, tales como las capacidades y los sistemas obligatorios de control de acceso, administracin de almacenamiento jerrquico, y muchas soluciones de espacio de usuario. ACL POSIX.1e son una extensin como consecuencia del modelo de permiso de POSIX.1. Apoyan ms escenarios permiso de grano fino y complejo que son difciles o imposibles de implementar en el modelo tradicional. Es lamentable que ninguna de estas reas ha sido formalmente estandarizados. Ya hay una mezcla salvaje de las implementaciones con sutiles diferencias e incompatibilidades. A medida que ms implementaciones disponibles, normalizacin en el futuro es cada vez ms improbable. En cuanto a POSIX ACL, a pesar de que son una mejora sustancial, sigue habiendo muchas restricciones:

Ms permisos de encontrar de grano sera de utilidad. Para directorios, el permiso de escritura incluye los derechos para aadir y eliminar archivos. Para los archivos, que permite la sobreescritura de los contenidos existentes, as como anexar. Para directorios, el bit sticky ayuda, pero su aplicacin es limitada. Soporte ext3 banderas y Ext2 como anexar e inmutable que se pueden establecer en un archivo para cada. permisos de ACL sera por usuario o por grupo. El creador de un archivo es tambin el dueo del archivo inicial. No hay modo de restringir el propietario del archivo de la modificacin de los permisos. Es imposible poner en prctica subir directorios de forma segura a nivel de sistema de archivos que no permiten modificar

los archivos existentes, o que no permiten a los usuarios crear archivos que otros usuarios puedan leer. No es posible delegar totalmente la administracin de un directorio a un usuario normal. Sera necesario garantizar que este usuario local con privilegios no se puede negar el acceso a los archivos por debajo de ese directorio y que este usuario puede cambiar los permisos, y, potencialmente, ceder o tomar posesin de archivos. En los sistemas tipo UNIX, es ms fcil evitar los problemas que en otros sistemas populares, pero estas soluciones causa complejidad y pueden contener errores. Tal vez sea mejor para resolver algunos de los problemas existentes en su raz. Todas las extensiones deben ser cuidadosamente diseado para simplificar la integracin con los sistemas existentes como Windows / CIFS y NFSv4. La forma de identificar a los usuarios de UNIX y los grupos de identificadores numricos es un problema en las grandes redes [ 18 ]. Al igual que el modelo de permiso de todo POSIX.1, las implementaciones actuales de las ACL POSIX.1e se basan en estos identificadores nicos. El mantenimiento de usuarios y bases de datos centrales del grupo se convierte cada vez ms difcil con el aumento de tamao de la red. Los protocolos CIFS y NFSv4 resolver este problema de manera diferente. En CIFS, los usuarios y grupos se identifican por identifers de seguridad nico en el mundo (SID). Los procesos tienen un nmero de SID, que determinan sus facultades. CIFS ACL puede contener SID de dominios diferentes. En NFSv4, los usuarios y grupos se identifican por una cadena de la forma usuario @ dominio ``''. Las implementaciones de NFSv4 se espera que las representaciones internas de los usuarios locales, como usuario nico o ID de grupo. ACL puede contener usuarios locales y no locales o los identificadores de grupo. Las implementaciones actuales de ACLs POSIX slo apoyo a los usuarios o los identificadores numricos de grupo en el dominio local. Permitir que los identificadores no locales en ACL parece posible, pero difcil. Una aplicacin consecuente requerira cambios sustanciales en el modelo de proceso. Como mnimo, adems de usuario no local y los identificadores de grupo en las entradas LCA, propiedad de los archivos y la propiedad de grupo de usuarios no locales y los grupos tendran que ser compatibles.

Agradecimientos