DOS nunca fue diseñado para ser un sistema operativo multiusuario ni de red. Unix, por el contrario, fue diseñado con ese propósito desde el principio. Consecuentemente, existen inconsistencias y lagunas o huecos entre los dos sistemas de archivos que Samba no sólo es consciente, sino que también proporciona soluciones para ellos. Uno de los mayores obstáculos es cómo Unix y DOS manejan los permisos de archivos.
Echemos un vistazo a cómo asigna Unix los permisos. Todos los archivos Unix tienen bits de lectura, escritura y ejecución para tres clasificaciones de usuarios: propietario (owner), grupo (group), y resto de usuarios (world). Estos permisos son visibles a la izquierda de los archivos cuando se ejecuta un comando ls -al sobre un directorio Unix. Por ejemplo:
-rwxr--r-- 1 tom users 2014 Apr 13 14:11 access.conf
Windows, por el contrarioo, tiene cuatro bits principales que usa con cualquier tipo de fichero: sólo lectura (read-only), de sistema (system), oculto (hidden), y archivo (archive). Puedes ver estos bits haciendo doble click con el botón derecho del ratón sobre el fichero y seleccionando el elemento de menú 'Propiedades'. Deberías ver algo similar a lo que muestra la Figura 5.6.5.1.
A continuación, la definición de cada uno de estos bits:
Consecuentemente, no hay uso para ninguno de los tres bits de ejecutable de Unix que están presentes en un archivo que se encuentra en un recurso compartido a través de Samba. Los archivos DOS, sin embargo, tienen sus propios atributos que necesitan ser preservados cuando estos son almacenados en un entorno Unix: los bits de archivo (archive), sistema (system), y oculto (hidden). Samba puede preservar estos bits mediante la reutilización de los bits de permisos de ejecución del archivo en el lado Unix -si lo hemos configurado para que lo haga, claro-. Mapear estos bits, sin embargo, tiene un desafortunado 'efecto secundario': si un usuario Windows almacena un fichero en un recurso compartido por Samba, y tú lo ves desde el lado Unix con el comando ls -al, algunos de los bits de permisos de ejecución no significarán lo que crees que deberían significar.
Tres opciones en Samba deciden si los bits serán o no mapeados: map archive, map system , y map hidden. Estas opciones mapean los atributos archivo (archive), sistema (system), y oculto (hidden) contra los bits de permiso de ejecución del propietario (owner), grupo (group) y resto de usuarios (world) del archivo, respectivamente. Puedes añadir estas opciones al recurso [data], estableciendo cada uno de sus valores como sigue:
[data] path = /home/samba/data browseable = yes guest ok = yes writeable = yes map archive = yes map system = yes map hidden = yes
Tras esto, intenta crear un archivo en el recurso desde Unix -por ejemplo, hello.java- y cambia los permisos del fichero a 755. Con estas opciones activadasd, deberías poder chequear los permisos en la parte de Windows y verías que cada uno de los tres valores aparece marcado en la caja de diálogo de Propiedades del archivo. ¿Y qué pasa con el atributo de sólo lectura? Por defecto, Samba 2.0 establece esto cuando un archivo no tiene configurado el bit de permiso de escritura para el propietario en la parte Unix. En otras palabras, puedes configurar este bit cambiando los permisos del fichero a 555.
Deberíamos advertirte que el valor por defecto para la opción map archive es yes, mientras que las otras dos opciones tienen un valor por defecto de no. Esto es así porque muchos programas no trabajarían correctamente si el bit de archivo no se almacena correctamente para archivos DOS y Windows. Los atributos de sistema (system) y oculto (hidden), sin embargo, no son críticos para la operatividad de los programas, así que quedan a la discreción del administrador del sistema.
La figura 5.7. resume los bits de permisos de Unix e ilustra cómo mapea Samba estos bits a atributos DOS. Advierte que los bits de grupo y del resto de usuarios de lectura/escritura no se traducen directamente a atributos DOS, pero ellos todavía retienen sus definiciones originales Unix en el servidor Samba.