Usando Samba - Diferencias entre Sistemas de Ficheros

Uno de los mayores problemas que Samba tiene que superar es la diferencia entre sistemas de ficheros Unix y no-Unix. Esto incluye cosas como manejar enlaces simbólicos, archivos ocultos, y ficheros de configuración (ficheros con 'punto'). Además, los permisos de ficheros también pueden convertirse en un dolor de cabeza si no han sido tenidos en cuenta. Eta sección describe cómo usar Samba para controlar algunas de estas diferencias, e incluso cómo agregar algunas nuevas funcionalidades.

Ficheros Ocultos y Vetados

Existen algunos casos en los que necesitamos asegurarnos de que un usuario no pueda acceder o ver determinados archivos. Otras veces, no queremos que un usuario pueda acceder al archivo -queremos ocultarlo cuando acceda a un directorio-. En sistemas Windows, un atributo de los ficheros permite ocultarlos en un listado de archivos. Con Unix, la manera tradicional de ocultar archivos en un directorio es precederlos de un punto (.). Esto evita que determinados archivos, como los de configuración, sean visibles ante la ejecución de un típico comando ls. Prohibir a un usuario el acceso a un fichero, sin embargo, implica trabajar con permisos sobre ficheros y/o directorios.

La primera opción de Samba que deberíamos discutir es la booleana hide dot files. Esta opción hace exactamente lo que dice. Cuando se establece a yes, la opción trata a los ficheros antecedidos por un punto (.) como ocultos. Si se establece a no, esos ficheros son siempre visualizados. Lo importante a recordar aquí es que los ficheros sólo están ocultos. Si el usuario ha seleccionado mostrar los ficheros ocultos (p.ej., usando la opción de menú Ver Archivos Ocultos en un cliente Windows 98), todavía serán visibles, independientemente del valor de ésta opción, como se ve en la Figura 5.2.

Figure: Archivos ocultos en el recurso [data].

En vez de simplemente ocultar los archivos que empiecen por un punto, puedes también especificar especificar un patrón de cadena para que Samba oculte determinados archivos, usando la opción hide files. Por ejemplo, supongamos que hemos especificado lo sigueinte en nuestro recurso de ejemplo [data]:

[data]
   path = /home/samba/data
   browseable = yes
   guest ok = yes
   writeable = yes
   case sensitive = no
   hide files = /*.java/*README*/
 

Cada entrada para ésta opción debe comenzar, terminar, o estar separada de otra con una barra (/), aunque sólo se liste un patrón. Esta convención permite que los espacios aparezcan en los nombres de archivos. En este ejemplo, el directorio compartido debería aparecer como ves en la Figura 5.3. De nuevo, advierte que hemos seleccionado la opción de ver archivos ocultos en nuestro cliente Windows.

Figure: Archivos ocultos en base a patrones de nombres de archivos.

Si queremos evitar que de ningún modo los usuarios puedan ver los archivos, podemos usar en su lugar la opción veto files. Esta opción, que usa la misma sintaxis que la opción hide files, especifica una lista de ficheros que nunca deberían ser vistos por el usuario. Por ejemplo, cambiemos el recurso [data] como sigue:

[data]
   path = /home/samba/data
   browseable = yes
   guest ok = yes
   writeable = yes
   case sensitive = no
   veto files = /*.java/*README*/
 

La sintaxis de esta opción es idéntica a la opción de configuración hide files: cada entrada debe comenzar, terminar o ser separada de otra entrada por una barra (/), aunque sólo halla un patrón. Haciendo esto, los ficheros hello.java y README simplemente desaparecerán del directorio, y el usuario no podrá acceder a ellos a través de SMB.

Hay otra cuestión que necesitamos controlar. ¿Qué ocurre si el usuario intenta borrar un directorio que contiene archivos vetados? Aquí es donde entra en juego la opción delete veto files. Si esta opción booleana se establece a yes, al usuario se le permitirá eliminar tanto los archivos normales como los que se encuentran vetados en el directorio, y el directorio mismo será eliminado. Si la opción se establece a no, el usuario no podrá eliminar los archivos vetados, y consecuentemente no serán eliminados. Desde la perspectiva del usuario, el usuario parecerá estar vacío, pero el directorio no podrá ser eliminado.

La directiva dont descend especifica una lista de directorios cuyos contenidos Samba no debería permitir que fueran visibles. Advierte que hemos dicho contenidos, no directorio. Los usuarios podrán entrar en el directorio, pero no podrán descender por el árbol del directorio -siempre verán una carpeta vacía-. Por ejemplo, usemos esta opción con una forma más básica del recurso definido al principio:

[data]
   path = /home/samba/data
   browseable = yes
   guest ok = yes
   writeable = yes
   case sensitive = no
   dont descend = config defaults
 

En adición, asumamos que el directorio /home/samba/data tiene los siguientes contenidos:

drwxr-xr-x 6 tom users 1024 Jun 13 09:24 .
 drwxr-xr-x 8 root root 1024 Jun 10 17:53 ..
 -rw-r--r-- 2 tom users 1024 Jun 9 11:43 README
 drwxr-xr-x 3 tom users 1024 Jun 13 09:28 config
 drwxr-xr-x 3 tom users 1024 Jun 13 09:28 defaults
 drwxr-xr-x 3 tom users 1024 Jun 13 09:28 market
 

Si el usuario entonces conecta al recurso, él o ella deberían ver los directorios mostrados en la Figura 5.4. Sin embargo, los contenidos de los directorios /config y /defaults aparecerían vacíos para el usuario, aunque existieran otras carpetas o archivos en ellos. En adición, los usuarios no podrán escribir datos en la carpeta (lo cual evita la posibilidad de crear un archivo con el mismo nombre que uno ya existente, pero invisible). Si un usuario intentase hacerlo, él o ella recibiría un mensaje de 'Acceso Denegado'. dont descend es una opción administrativa, no de seguridad, y no es sustituta de una buena política de permisos de archivos.

Figure: Contenidos del recurso [data] con 'dont descend'.

Enlaces

Los sistemas de ficheros DOS y NT no tienen enlaces simbólicos; los sistemas Windows 95/98/NT se aproximan a ellos con sus 'Accesos Directos'. Así, cuando un cliente intenta abrir un enlace simbólico en un directorio de un recurso compartido por un servidor Samba, Samba intenta seguir el enlace al archivo verdadero y permite al cliente abrirlo, como si estuviera en una máquina Unix. Si no quieres permitir esto, configura la opción follow symlinks:

[data]
   path = /home/samba/data
   browseable = yes
   guest ok = yes
   writeable = yes
   case sensitive = no
   follow symlinks = no
 

Puedes testear esto creando un directorio en el servidor Unix dentro del recurso como el usuario que va a acceder a él. Introduce los siguientes comandos:

%
 mkdir hello; cd hello %
 cat "This is a test" >hello.txt %
 ln -s hello.txt "Link to hello"
 

Esto resulta en los dos archivos mostrados en la Figura 5.5. Normalmente, si haces click sobre cualquiera de ellos, recibirás un archivo que tiene el texto 'This is a test' dentro de él. Sin embargo, con la opción follow symlinks establecida a no, deberías recibir un error similar al de la caja de diálogo de la Figura 5.5 si hicieras click sobre 'Link to hello.'

Figure: Ventana de error al intentar seguir enlaces simbólicos prohibidos por Samba.

Finalmente, hablaremos de la opción wide links. Esta opción, si está a yes, permite al usuario cliente seguir enlaces simbólicos que apunten fuera del árbol del recurso, incluyendo archivos o directorios en la otra parte del enlace. Por ejemplo, asumamos que hemos modificado el recurso [data] como sigue:

[data]
   path = /home/samba/data
   browseable = yes guest
   ok = yes
   writeable = yes
   case sensitive = no
   follow symlinks = yes
   wide links = yes
 

Con tal de que la opción follow symlinks esté activada, esto causará que Samba siga todos los enlaces simbólicos fuera del actual árbol del recurso. Si creamos un archivo fuera del recurso (por ejemplo, en algún directorio 'home' de usuario) y luego creamos un enlace a él en el recurso como sigue:

ln -s ~tom/datafile ./datafile
 

entonces podrás abrir el fichero del directorio de Tom, en función de los permisos que tenga el archivo.

Opciones de Sistemas de Archivos

La Tabla 5.4 muestra un resumen de las opciones que hemos discutido. Recomendamos los valores por defecto para la mayoría, excepto para aquéllas listadas en las siguientes descripciones.

unix realname

Algunos programas requieren un nombre de usuario completo para poder operar. Por ejemplo, un programa de correo de Windows frecuentemente necesita asociar un nombre de usuario con un verdadero nombre. Si tu fichero de contraseñas de sistema contiene los nombres verdaderos de los usuarios en el campo GCOS, la opción unix realname instruye a Samba para proporcionar esta información a los clientes. Sin esto, el nombre del usuario simplemente será su ID de login. Por ejemplo, si tu ficheros de contraseñas de Unix contiene la siguiente línea:

rcollins:/KaBfco47Rer5:500:500:Robert Collins:
 /home/rcollins:/bin/ksh
 

Y la opción en el fichero de configuración es:

[global]
   unix realname = yes
 

entonces el nombre Robert Collins será facilitado a cualquier cliente que solicite el verdadero nombre del usuario rcollins. Normalmente no necesitarás meterte con esta opción.

dont descend

La opción dont descend puede ser usada para especificar varios directorios que deberían aparecer vacíos al cliente. Advierte que el directorio mismo todavía aparecerá. Sin embargo, Samba no mostrará los contenidos del directorio al usuario cliente. No es una buena opción usar esto como una medida de seguridad (un usuario podría encontrar una forma de dar un rodeo); esto sólo es una utilidad para evitar determinadas visualizaciones en los clientes de directorios que tengan archivos delicados. Mira nuestro anterior ejemplo en esta sección.

follow symlinks

Esta opción, controla si Samba seguirá un enlace simbólico en el sistema operativo Unix objetivo, o si debería retornar un error al cliente. Si la opción se establece a yes, el enlace será interpretado como el propio fichero.

getwd cache

Esta opción global especifica si Samba debería usar una caché local para la llamada a sistema Unix getwd() (get current working directory). Puedes cambiar el valor a yes como sigue:

[global]
   getwd cache = no
 

Establecer esta opción a yes puede incrementar significativamente el tiempo que se toma para resolver el directorio de trabajo, especialmente si la opción wide links se establece a no. No deberías modificar esta opción en condiciones de configuración normales.

wide links

Esta opción especifica si el usuario cliente puede seguir enlaces simbólicos que apunten fuera del árbol del directorio compartido. Esto incluye cualesquiera archivos o directorios en la otra parte del enlace, con tal de que los permisos de este sean apropiados para el usuario. El valor por defecto para esta opción es yes. Advierte que esta opción no será tenida en cuenta si la opción follow symlinks se establece a no. Establecer esta opción a no ralentiza al demonio smbd considerablemente.

hide files

La opción hide files proporciona uno o más patrones de directorio o archivo para Samba. Cualquier fichero coincidente será tratado como archivo oculto para la perspectiva del cliente. Advierte que esto simplemente significa que el atributo DOS hidden es activado, lo cual puede significar o no que el usuario pueda ver ese archivo.

Cada entrada en la lista debe comenzar, terminar o estar separada de otra entrada por una barra (/), aunque sólo halla un elemento. Esto permite la aparición de espacios en la lista. Los asteriscos pueden ser usados como comodines para representar cero o más caracteres. Las interrogaciones pueden ser usadas para representar exactamente un carácter. Por ejemplo:

hide files = /.jav*/README.???/
 

hide dot files

La opción hide dot files oculta cualesquiera archivos en el servidor que comiencen por un punto (.), en orden a imitar la funcionalidad de varios comandos de shell que están presentes en sistemas Unix. Al igual que con hide files, aquellos archivos que comiencen con un punto tendrán el atributo DOS 'hidden' activado, lo cual no garantiza que el cliente no podrá verlo. El valor por defecto para esta opción es yes.

veto files

Más fuerte que el estado de oculto es el estado proporcionado por la opción de configuración veto files. Samba nunca admitirá la existencia de estos archivos. No podrás listarlos o abrirlos desde el cliente. En realidad, esto no es una gran medida de seguridad. Simplemente es un mecanismo para evitar que programas de PC puedan borrar archivos especiales.

La sintaxis de esta opción es idéntica a la de la opción hide files: cada entrada debe comenzar, terminar, o estar separadas de otras entradas por un carácter barra (/), aunque sólo aparezca un elemento. Los asteriscos pueden ser usados como comodines para representar cero o más caracteres. Las interrogaciones pueden ser usadas para representar exactamente un carácter. Por ejemplo:

veto files = /*config/*default?/
 

Esta opción es simplemente administrativa -no es sustituta de una buena política de permisos de ficheros-.

delete veto files

Esta opción le dice a Samba que elimine ficheros vetados cuando un usuario intente eliminar el directorio en el que estos residen. El valor por defecto es no. Esto significa que si un usuario intenta eliminar un directorio que contenga un fichero vetado, el fichero (y el directorio) no serán eliminados. En su lugar, el directorio permanecerá y parecerá estar vacío desde la perspectiva del usuario. Si se establece a yes, el directorio y los archivos vetados serán eliminados.