especificando permisos complejos en archivos y carpetas en Unix

especificando permisos complejos en archivos y carpetas en Unix

En el trabajo dirijo un grupo responsable de la gestión y seguridad de los datos. Tenemos la necesidad de especificar permisos complejos en archivos y carpetas más allá del rwx estándar de usuario/grupo/mundo. Las investigaciones muestran que esto se puede hacer con atributos de archivo extendidos (comandos setfacl, getfacl) en archivadores que ejecutan NFSv4. Los declarantes en el trabajo ejecutan NFSv3. Cada vez que le pregunto al grupo de TI sobre la conversión, siempre responden "es demasiado lento, demasiado difícil, no es seguro ni estable, etc." actualizar a NFSv4 sin proporcionar datos o cronogramas para fundamentar las afirmaciones. Como resultado, terminamos creando múltiples copias de datos donde el directorio A tiene archivos que el grupo A puede ver y el directorio B tiene archivos que el grupo B puede ver.

Me preguntaba un par de cosas:

  1. ¿Son ciertas las afirmaciones? ¿La conversión de NFSv3 a NFSv4 con atributos de archivo extendidos habilitados afecta gravemente al rendimiento? ¿Hay otros elementos a considerar? por ejemplo, supongo que es posible que algunas aplicaciones no estén codificadas para interpretar correctamente estos atributos de archivos extendidos.
  2. Además de acls en NFSv4, ¿existe otra solución o método para aplicar permisos complejos? la mayoría de las máquinas en el trabajo ejecutan SLES11 o SLES12.

Agradezco cualquier ayuda o dirección que pueda ofrecer... ¡gracias!

Respuesta1

NFS 4 puede ser mucho más seguro y seguramente es estable, disponible desde 2003, si mal no recuerdo. También hay versiones más nuevas, 4.1 y 4.2. Es bastante fácil de actualizar si no habilita ninguna de las funciones avanzadas.

  1. El rendimiento puede ser un poco mejor en nfs 3, debido al uso de udp & tcp; nfs 4 es solo tcp. Pero eso realmente no hace una gran diferencia en la mayoría de los escenarios. En realidad, se puede compensar, porque en tcp, cuando se pierden paquetes, sólo se retransmiten estos paquetes perdidos, a diferencia de udp. También hay delegación en nfs 4, lo que puede mejorar el rendimiento. El cifrado puede afectar mucho el rendimiento, pero es una opción, no es obligatorio utilizar estándares de seguridad más altos en nfs 4, pero están disponibles si es necesario.
    Realmente no puedo decir acerca de las incompatibilidades de aplicaciones usando nfs v4. Lo he usado para operaciones de copia y movimiento de archivos y transmisión de video sin problemas.

  2. No puedo darle una respuesta definitiva sobre esto, aunque creo que la ausencia de alternativas dio origen a nfs v4. Se podría utilizar SMB/CIFS; No lo considero una alternativa nativa porque es un protocolo de Windows, sin embargo la implementación de UNIX/Linux es excelente. Aunque supongo que sería un desafío mayor implementarlo en servidores y clientes Linux que nfs v4.

Una razón por la que su equipo de TI se muestra reacio a cambiar a la versión 4 puede ser la compatibilidad y el soporte del sistema operativo: tanto los servidores como los clientes deben admitirlo. Quizás haya sistemas operativos más antiguos, como SLES 11 sin SP, que no son compatibles con SuSE y prefieren evitar cambiar sus configuraciones.

También existe la opción de compartir usando nfs v3 y v4. Puede probarlo en algunos directorios antes de proceder a cambiar completamente a v4.

información relacionada