En esta sección, se incluyen los siguientes temas:
Para obtener más información acerca del protocolo NFS, utilice estos temas:
NFSv2 and NFSv3 Security (RFC 2623) (http://www.ietf.org/rfc/rfc2623.txt)
NFSv4 Protocol (RFC 7530) (http://www.ietf.org/rfc/rfc7530.txt)
NFSv4.1 Protocol (RFC 5661) (https://tools.ietf.org/html/rfc5661)
Para obtener información acerca de otros protocolos admitidos, consulte las secciones siguientes:
Cada recurso compartido tiene propiedades específicas del protocolo que definen el comportamiento de protocolos diferentes para ese recurso compartido. Estas propiedades pueden ser definidas para cada recurso compartido o heredadas del proyecto del recurso compartido. En la siguiente tabla, se muestran las propiedades del protocolo NFS y los valores posibles.
|
Es posible definir excepciones para el modo de recurso compartido global para clientes o juegos de clientes. Para ello, se deben definir modos de recurso compartido específicos para el cliente o excepciones. Para restringir el acceso a determinados clientes, defina el modo de recurso compartido global en none y otorgue cada vez más acceso a grupos más pequeños. Por ejemplo, puede crear un recurso compartido con el modo de recurso compartido global definido en none, el cual deniega el acceso a todos los clientes y, luego, otorgar acceso de solo lectura a un subjuego de los clientes. Además, puede otorgar acceso de lectura/escritura a un subjuego aún más pequeño de los clientes y, finalmente, solo los host de confianza tendrán acceso root y de lectura/escritura.
Los modos de recurso compartido específicos del cliente tienen prioridad por sobre el modo de recurso compartido global. El cliente tiene permitido el acceso en función del modo de recurso compartido específico del cliente que se especifique en una excepción. Si no hay excepciones, el cliente recibe acceso en función del modo de recurso compartido global.
|
Para cada cliente o juego de clientes, debe especificar si el cliente tiene acceso de solo lectura o acceso de lectura y escritura al recurso compartido. Si está configurando una excepción de NFS, también debe especificar si el cliente tiene privilegios de usuario root o si se lo debe considerar como un usuario sin acceso root.
Los grupos de red se pueden usar para controlar el acceso de las exportaciones del NFS. Sin embargo, gestionar grupos de red puede ser complejo. En su lugar, considere usar reglas de subred de IP o reglas de dominio DNS.
Si se usan grupos de red, se resolverán desde NIS o LDAP, según qué servicio esté activado. Si se usa LDAP, cada grupo de red se debe encontrar en la ubicación por defecto, ou=Netgroup, (DN de base), y se debe usar un esquema estándar.
El componente de nombre de usuario de una entrada de grupo de red generalmente no afecta el NFS; solo el nombre del host resulta significativo. Los nombres de host incluidos en grupos de red deben ser canónicos y, si se resuelven mediante DNS, deben ser completos. Es decir, el subsistema NFS intentará verificar que la dirección IP del cliente solicitante se convierta en un nombre de host canónico que coincida con el FQDN especificado o con uno de los miembros de uno de los grupos de red especificados. Esta coincidencia debe ser exacta, incluidos todos los componentes del dominio; de lo contrario, la excepción no coincidirá y se intentará la excepción siguiente. Para obtener más información sobre la resolución de nombres de hosts, consulte DNS.
A partir de la versión de software 2013.1.0, los usuarios del cliente UNIX pueden pertenecer a un máximo de 1024 grupos sin una degradación del rendimiento. Las versiones anteriores admitían hasta 16 grupos por usuario del cliente UNIX.
En la CLI, todas las excepciones y los modos de recursos compartidos de NFS se especifican mediante una única cadena de opciones para la propiedad sharenfs. Esta cadena es una lista de valores separados por comas. Debe comenzar con ro, rw, on u off, como analogía de los modos de recursos compartidos globales descritos para la BUI.
|
En el ejemplo siguiente, se configura el modo de recurso compartido para todos los clientes en solo lectura. Los usuarios root de todos los clientes tendrán acceso a los archivos del recurso compartido como si fueran el usuario genérico nobody.
set sharenfs=ro
También se podrá agregar cualquiera de las opciones nosuid y anon, o ambas. Por lo tanto, para definir la asignación de todos los usuarios desconocidos con el UID 153762, debería especificar lo siguiente:
set sharenfs="ro,anon=153762"
Se pueden especificar excepciones adicionales de NFS si se anexa texto con el formato option=collection, donde option equivale a ro, rw o root, y define el tipo de acceso que se otorgará a la recopilación de clientes. La recopilación es especificada por el carácter de prefijo de la tabla Tipos de cliente y un nombre de dominio/nombre de host DNS o número de red CIDR. Por ejemplo, para otorgar acceso de lectura y escritura a todos los hosts del dominio sf.example.com y acceso root a los de la red 192.168.44.0/24, puede utilizar:
set sharenfs="ro,anon=153762,rw=.sf.example.com,root=@192.168.44.0/24"
Los nombres de grupos de red se pueden utilizar en cualquier lugar donde se puede utilizar un nombre de host completo. Por ejemplo, puede permitir el acceso de lectura y escritura al grupo de red engineering de la siguiente manera:
set sharenfs="ro,rw=engineering"
En general, no se especifica la codificación del juego de caracteres utilizada para el nombre de archivos. Los protocolos NFSv3 y NFSv2 no especifican el juego de caracteres. NFSv4.0 y NFSv4.1 deberían usar UTF-8, pero no todos los clientes lo hacen y el servidor no aplica esta restricción. Si la opción de solo UTF-8 está desactivada para un recurso compartido, estos nombres de archivos se escriben literalmente en el sistema de archivos sin tener información de su codificación. Eso significa que solo pueden ser interpretados por los clientes que utilizan la misma codificación. Sin embargo, SMB exige el almacenamiento de nombres de archivos como UTF-8 para que puedan ser interpretados por el servidor. De esta manera, resulta imposible admitir codificaciones arbitrarias de clientes y, al mismo tiempo, se permite el acceso mediante SMB.
A fin de admitir dichas configuraciones, la codificación del juego de caracteres se puede configurar para todos los recursos compartidos o por cliente. Se admiten las siguientes codificaciones de juegos de caracteres:
|
El comportamiento por defecto consiste en dejar la codificación del juego de caracteres sin especificar (pasarla por alto). La BUI permite elegir del juego de caracteres mediante el mecanismo de listas de excepciones estándar. En la CLI, cada juego de caracteres se convierte en una opción con uno o varios hosts; * indica la configuración de la totalidad del recurso compartido. Por ejemplo:
hostname:shares default> set sharenfs="rw,euc-kr=*"
Compartirá el sistema de archivos con euc-kr como la codificación por defecto. Por ejemplo:
hostname:shares default> set sharenfs="rw,euc-kr=host1.domain.com,euc-jp=host2.domain.com"
Utilice la codificación por defecto para todos los clientes excepto host1 y host2, los cuales utilizarán euc-kr y euc-jp, respectivamente. El formato de las listas del host es igual al de otras opciones de CLI NFS.
Recuerde que algunos clientes NFS no admiten correctamente configuraciones locales alternativas. Para obtener más información, consulte la documentación del cliente NFS.
Los modos de seguridad se configuran por recurso compartido. En la siguiente lista, se describe la configuración de seguridad de Kerberos:
krb: autenticación de usuario final mediante Kerberos V5.
krb5i: krb5 más protección de integridad (los paquetes de datos están protegidos contra alteraciones).
krb5p: krb5i más protección de privacidad (los paquetes de datos están protegidos contra alteraciones y cifrados).
Los modos de seguridad se especifican cuando se anexa texto con el formato option=mode, donde option equivale a sec y mode es la configuración de seguridad. Por ejemplo:
hostname: shares default> set sharenfs="sec=krb5"
Al definir modos de seguridad, se pueden especificar combinaciones de varios tipos de Kerberos. La combinación de modos de seguridad permite el montaje de clientes con cualquiera de los tipos de Kerberos indicados en la lista, como se muestra en la siguiente tabla.
|
Puertos reservados
Para configurar puertos reservados para la autenticación del sistema, use resvport como se muestra en el siguiente ejemplo:
set sharenfs="sec=sys,rw,resvport"
Tenga en cuenta que resvport solo se puede usar con el modo de seguridad de autenticación de sistema sec=sys.