Zfs: Soporte NFS / POSIX ACL

Lamentablemente, las cosas son un poco más complicadas de lo que parece.

Internamente, ZFS admite y aplica completamente las ACL de estilo NFS. Desafortunadamente, en Linux, las herramientas existentes solo manipulan las ACL de estilo Posix. Se ha realizado algún trabajo para llevar el modelo NFS ACL a Linux bajo el nombre Rich-ACLs. Para integrarse con la nueva cadena de herramientas Rich-ACL, ZFS necesita proporcionar una interfaz virtual system.richacl xattr. Este xattr no se almacenaría como otros xattrs, sino que se integraría con zfs_getacl () y zfs_setacl (). Este gancho xattr sería responsable de traducir un vsecattr_t hacia y desde un flujo lineal de bytes para el xattr.

Posix ACL se puede admitir fácilmente agregando algunos ganchos y aprovechando las funciones de soporte de Posix ACL existentes. Sin embargo, puede ser mejor que no se implementen para evitar problemas de coherencia entre Posix y Rich ACL (NFS / ZFS).

Gracias por la descripción. Creo que POSIX ACL también puede ser útil si hay algunas aplicaciones que admiten POSIX ACL. Según recuerdo, la samba tiene algo así. rsync tiene soporte ACL, pero no estoy seguro de que sea solo POSIX, porque el hombre solo dice "ACL". No conozco otras aplicaciones.
Solo quiero decir que no son inútiles incluso con la presencia de otras ACL. Y puede considerarse que se implementará en el futuro.

Resumen del trabajo requerido

Internamente, ZFS admite y aplica completamente las ACL de estilo NFS. Desafortunadamente, en Linux, las herramientas existentes solo manipulan las ACL de estilo Posix. Se ha realizado algún trabajo para llevar el modelo NFS ACL a Linux bajo el nombre Rich-ACLs (pdf). Para integrarse con la nueva cadena de herramientas Rich-ACL, ZFS necesita proporcionar una interfaz virtual system.richacl xattr. Este xattr no se almacenaría como otros xattrs, sino que se integraría con zfs_getacl () y zfs_setacl (). Este gancho xattr sería responsable de traducir un vsecattr_t hacia y desde un flujo lineal de bytes para el xattr.

Posix ACL se puede admitir fácilmente agregando algunos ganchos y aprovechando las funciones de soporte de Posix ACL existentes. Sin embargo, puede ser mejor que no se implementen para evitar problemas de coherencia entre Posix y Rich ACL (NFS / ZFS).

¿Qué pasa con una opción de montaje / propiedad del sistema de archivos sobre CUAL modelo de seguridad se debe hacer cumplir? (y tal vez el otro completamente oculto incluso de las herramientas de administración, como setfacl / getfacl).
En el mundo Linux, las ACL enriquecidas casi no se utilizan. Las ACL Posix se utilizan mucho más. En mis configuraciones típicas, la ausencia de ACL para un sistema de archivos es un éxito.
Creo que de esta forma podemos conseguir una implementación de ACL funcional (Posix) en mucho menos tiempo.

A mí también me gustaría ver el soporte POSIX ACL integrado en ZFS en Linux. Linux es POSIX, y hasta que las RichACL sean más convencionales (o al menos en el kernel), creo que la integración de POSIX en ZFS en Linux tiene sentido.

¡Me encantaría ver esto incluido! Fue casi un espectáculo para nosotros, pero decidimos vivir sin él durante unos meses.

Cuando las ACL se manejan de forma limpia, debemos asegurarnos de que se fusiona el siguiente parche para resurgir la propiedad aclmode. Este cambio ya se ha realizado en las implementaciones de Illumos y FreeBSD.

Problema 742: resucite la propiedad "aclmode" de ZFS
https://www.illumos.org/issues/742
https://github.com/illumos/illumos-gate/commit/a3c49ce110f325a563c245bedc4d533adddb7211

Es posible mapear Posix <-> NFSv4 ACL.
IETF tiene un borrador sobre ese mapeo: http://tools.ietf.org/id/draft-ietf-nfsv4-acl-mapping-03.txt
Pero solo especifica claramente Posix => NFSv4 (unidireccional).

Creo que el enfoque de mapeo es teóricamente el mejor, pero es más propenso a errores que otros, ya que el mapeo 1: 1 no es posible.
Siempre habrá casos de esquina en los que a un usuario se le niegue (o peor aún, se le otorgue) un privilegio que no está destinado a ser denegado (o peor aún, otorgado).
Al menos debería venir con una "gran advertencia".
Pero no es prudente tener una función de _seguridad_ que _debe_ aproximarse a lo que debería hacer.
Propuesta: en "equívoco" NFSv4 acl no permitir CUALQUIER acceso y error de impresión en el registro del kernel.
Problema con esa propuesta: las instantáneas no se pueden corregir manualmente.
Para configurarlos, no debería ser un problema, ya que puede verse simplemente como un formato en disco "extraño" para las ACL de Posix.
Una herencia mucho más configurable de las ACL de NFSv4 crea otro conjunto de problemas que resolver.

Creo que un primer paso esta implementación debería ser capaz de:

• escribir ACL POSIX, leer y hacer cumplir lo que ha escrito.
• escríbalos en el disco como NFSv4 ACL para que otras implementaciones también puedan leerlos y aplicarlos según lo previsto.
• FALLAR EN GRANDE con ACL NFSv4 no trivialmente asignables escritas por otras implementaciones.
  ** negar CUALQUIER acceso a esos elementos.
  ** no permitir que los usuarios creen archivos en directorios con indicadores de herencia "particulares"
  ** tal vez tenga un "comportamiento de falla" configurable por sistema de archivos con el valor predeterminado más seguro. (¿y para instantáneas?)

En pasos sucesivos, la lógica de mapeo NFSv4 => Posix se puede ajustar y hacer mucho más personalizable.

¿Alguna idea mejor?

Este me parece un punto de partida razonable, solo unos pocos comentarios.

Si bien un mapeo perfecto 1: 1 no es posible, las cosas no son tan malas. Como señala, hay un IETF Posix -> NFSv4 mapeo bien especificado que se puede usar para configurar las ACL correctas en el disco. Una vez configurado en disco como SA, la implementación de zfs existente debería comenzar a imponerlos independientemente de los ganchos ACL genéricos de Linux en el VFS.

Luego, por supuesto, deberá implementar un NFSv4 razonable -> mapeo Posix para leer las ACL. Sin embargo, ya existen implementaciones razonables de esto. Por ejemplo, el servidor del kernel Linux nfs que se ve obligado a almacenar todas sus ACL NFSv4 como ACL Posix, que es una operación con pérdidas. Además, a largo plazo, exponer la ACL nfsv4 / zfs sin procesar sería algo bueno para el servidor del kernel nfs. Potencialmente, podría evitar una conversión NFSv4 -> Posix -> NFSv4 sin sentido.

Finalmente, nos gustaría tener un conjunto de pruebas para verificar que lo hicimos bien. Después de todo, esta es una característica de seguridad. Afortunadamente, tengo entendido que ya existen varios conjuntos de pruebas buenos.

Hay un trabajo sobre los richacls de Aneesh kumar, Andreas Gruenbacher sobre el trabajo anterior realizado por Greg Banks. Se enviaron parches para la línea principal 3.1 fusionada, pero debido a algunos cambios, llevará tiempo y se fusionará en la próxima versión.
Enlace a parches: - https://lkml.org/lkml/2011/10/18/279

Una vez que esto llegue a la línea principal, podemos utilizarlos para admitir nfsv4acls para ZFS.

Una vez que esto llegue a la línea principal, podemos utilizarlos para admitir nfsv4acls para ZFS.

¿Y qué pasa con las ACL POSIX? Brian dijo que no es tan difícil implementarlos usinx xattr. ¿Puede alguien hacer esto también, por favor? :)

ZFS es compatible con nfsv4acls, por lo que en mi humilde opinión deberíamos dar soporte para nfsv4acls primero y ver si las acls posix son realmente necesarias. Si es así, entonces podemos encontrar la manera de definir un mapeo entre ellos.

No veo ninguna razón por la que no se puedan hacer ambas cosas. Maxximino está trabajando actualmente en el soporte de la interfaz system.posixacl xattr a través de una traducción bien documentada. Se puede admitir la adición de la interfaz system.richacl xattr cuando está disponible una cadena de herramientas integrada y real.

"Actualmente trabajando" como me lo permiten las tareas académicas y laborales, pero en alta prioridad para el tiempo "libre".
Ya he examinado el código con licencia CDDL de IllumOs y encontré un código que hace la traducción de NFSv4 <-> posix acl. Debe ser una base sólida, desde el punto de vista de la corrección. Detalles a solicitud.

Sé que solaris solo proporciona dos copias de chmod para administrar las ACL. Desafortunadamente, esto es muy incómodo y torpe. Propongo que usemos un programa auxiliar, setzacl, getzacl o similar para proporcionar facilidades de visualización y modificación de ACL en zfs en linux. Preferiblemente, la interfaz debe crearse para ser similar (o compatible con) solaris chmod, posiblemente mejorada, pero estandarizada en ambas implementaciones de zfs linux, y preferiblemente capaz de manejar futuros sistemas de archivos con acls "nfs4". (Si alguien puede explicar por qué se llaman ACL nfs4, ¡también sería de gran ayuda!)

Agregaría que a los usuarios de Samba les gustaría seguir con las ACL nfs4, sobre todo porque se acercan más a las ACL de Windows NTFS que coinciden función por función. Esto es importante cuando desea utilizar Samba como servidor para las carpetas de inicio y de perfil de los usuarios en un entorno de Active Directory donde las versiones más recientes de Windows comprueban ACL específicas. Además, la interoperabilidad de Windows era uno de los objetivos de diseño de ZFS en los días de Sun, por lo que sería triste verlo desaparecer ...

Dicho esto, entiendo completamente el impulso para el cumplimiento de POSIX.

aarcane: consulte http://wiki.linux-nfs.org/wiki/index.php/ACLs para conocer la historia de las ACL de NFSv4.

Estoy experimentando con un recurso compartido de Samba 4 DC y ZFS CIFS en este momento; el sistema base es ubuntu 12.04.

Los clientes de XP Pro SP3 pueden ver y administrar Active Directory (usuarios y computadoras) y establecer los permisos NTFS correctamente en las carpetas compartidas desde EXT4.

Las carpetas compartidas desde ZFS se vuelven imposibles de navegar a través de CIFS tan pronto como modifica sus permisos a través de la interfaz gráfica de usuario de XP (aunque aún puede acceder a ellas, como se esperaba, desde la línea de comandos del servidor).

¿Supongo que es el resultado de los problemas descritos en el hilo anterior? Cualquier idea alternativa será bien recibida.

Habilitar la administración completa de NTFS ACL a través de Samba 4 sería una gran ventaja para ZFS.

¿Puede publicar más detalles sobre su problema? Versión exacta de Samba4, ¿qué servidor de archivos está usando (smbd o ntvfs) y alguna configuración relevante? (por ejemplo, ¿está usando vfs_acl_xattr o algo similar?)
Quizás abra otro problema, SI la misma configuración de Samba4 funciona sobre extY montado sin la opción "acl".

Acerca de la manipulación de ACL reales de NFSv4 (tipo NTFS) a través de Samba, esto se puede hacer _de forma limpia_ solo después de que los parches "Rich ACL" se fusionen en el kernel.

Gracias Maxximino.
Estoy usando Samba 4.0.0 alpha19.
Solo estoy intentando servidor archivos con ntvfs (sudo / usr / local / samba / sbin / samba -i -M single) - que sirve recursos compartidos de netlogon y sysvol desde ext4 y mis recursos compartidos de zfs desde un par de unidades duplicadas con aclinherit = conjunto de paso a través.
No se está utilizando ningún módulo vfs_acl_xattr.

"Sobre la manipulación de ACL reales de NFSv4 (tipo NTFS) a través de Samba, esto se puede hacer de forma limpia sólo después de que los parches" Rich ACL "se fusionen en el kernel".

Por lo que tengo entendido, los parches oficiales de richacls solo son compatibles con EXT4, ¿estás diciendo que si, por ejemplo, uso opensuse (con richacls incluido de forma predeterminada) o parcheo richacls en ubuntu / debian, zfs + samba4 + ntfs acls debería "empezar a funcionar? "?

He reproducido tu problema.
No está utilizando vfs_acl_xattr explícitamente, pero Samba4 está haciendo lo mismo "silenciosamente". Guarda sus ACL en el xattr llamado "security.NTACL" (que puede ver con getfattr -n security.NTACL $ FILENAME; y eliminar con setfattr -x security.NTACL $ FILENAME).
Ese atributo es considerado solo por Samba, no por nada en el kernel de zfs / linux. Dado que un programa perl simple que guarda valores de / dev / urandom en xattrs en zfs, puede leerlos sin dañar, realmente creo que es un problema de Samba4.
El problema se muestra solo en zfs PROBABLEMENTE porque en otros fs puede mapear sus ACL en Posix ACL en lugar de usar xattrs.

No, simplemente parchear un kernel con parches enriquecidos acl no es suficiente. Cuando esos parches aterrizan en la línea principal, es posible comenzar a integrar un soporte enriquecido de acl en zfs.

Solo estoy construyendo Samba 4 en Suse; Creo que estaba a punto de reproducir tu reproducción desde un ángulo diferente.
Me salvó el dolor.

¿Quizás una solución alternativa razonable (a corto plazo) sería servir archivos desde zfs a través de un entorno estable de Samba 3, autenticando contra un Samba 4 DC en un Linux-VServer diferente, por ejemplo?

A mediano plazo, la utilidad de tener recursos compartidos CIFS basados ​​en ZFS combinados con Samba 4 AD, todo basado en un sistema operativo Linux con excelente soporte de hardware genérico _en la misma máquina_ no puede ser sobrecargado. Las aplicaciones para pequeñas empresas y organizaciones sin fines de lucro son enormes.

Gracias por todo el trabajo hasta ahora.

Me topé con el siguiente hilo:
https://lists.samba.org/archive/samba/2012-August/168660.html

El resumen es que Samba 4 tiene un módulo acl llamado vfs_zfsacl, que se usa en Solaris, de modo que Samba puede usar las acls nativas de ZFS. ¿Sería posible utilizar este módulo con zfsonlinux? ¿Están disponibles las API necesarias para el espacio de usuario en Linux?

@kisg Esa es una buena pregunta, esta es la primera vez que escucho del módulo vfs_zfsacl para Samba. Algunas personas necesitarán hacer un trabajo preliminar para determinar qué interfaz esperan. Dependiendo de lo que sea, es posible que podamos proporcionárselo. Aunque si no se realiza ninguna traducción, aún tendrá el problema de no poder administrar las ACL en la caja de Linux.

Eché un vistazo rápido a la fuente.
Puede encontrar la versión de rama estable de Samba v4-0 de vfs_zfsacl.c aquí: git.samba.org .

Simplemente se convierte de la representación interna de Samba a la API nativa SunOS NFSv4 acl / facl. Esta API también se implementa en FreeBSD utilizando un contenedor de espacio de usuario delgado alrededor de su propia implementación de NFSv4 acl.

Según este análisis, no podemos reutilizar esta implementación en Linux. En cambio, si se realiza la integración richacl de zfsonlinux, podríamos usar la biblioteca librichacl para crear un módulo vfs_richacl igualmente simple (con suerte, menos de 1000 líneas) para Samba.

Desde mi mirada superficial a los parches del kernel de richacl, parece que la integración de zfsonlinux podría incluso realizarse sin realmente parchear el kernel, simplemente extrayendo las porciones requeridas (estructuras de datos y conversión xattr) del código richacl en el árbol zfs para las versiones del kernel que no lo admite de forma nativa. Esto es importante para nosotros, porque a nosotros (mi empresa) nos gustaría ejecutar un kernel Ubuntu LTS estándar y solo incorporar zfsonlinux como módulo adicional.

Sin embargo, no estoy seguro de si richacl todavía se mantiene (su repositorio no está realmente actualizado) y si está en camino para su inclusión en el kernel de vainilla.

Me comuniqué con el autor del conjunto de parches richacl. Me señaló el siguiente módulo experimental richacl vfs: v4acls-experimental / samba.git

Así que parece que casi todas las piezas están en su lugar (o al menos existen en forma experimental) excepto por el soporte richacl en el propio zfs.

¿Quizás portar libsunacl.c a linux podría ser suficiente desde el lado de samba?

http://sourceforge.net/projects/libsunacl/

pero por lo que tengo entendido "aclmode" seguirá faltando en zfsonlinux.

Ni siquiera sé por qué todavía no tenemos algún tipo de soporte de ACL. Porque tener
zfs acls no se ha encendido? Conozco el código de un chmod y un ls
exist.a getfacl style getzacl ya debería haber sido proporcionado. Estoy seguro
Sin embargo, hay una buena razón para la falta de ACL.
El 15 de febrero de 2013 a las 2:07 p.m., "franx" [email protected] escribió:

¿Quizás portar libsunacl.c a linux podría ser suficiente desde el lado de samba?

http://sourceforge.net/projects/libsunacl/

pero por lo que tengo entendido "aclmode" seguirá faltando en zfsonlinux.

-
Responda a este correo electrónico directamente o véalo en Gi

zfs acl es compatible
prueba:
cree un archivo en un recurso compartido smb en otro sistema de archivos con la opción de montaje acl habilitada, configure ACL en Windows.

mover ese archivo en un volumen zfsonlinux con aclinherit = passthrough
los acls se conservan ..

Wath atm no tiene una solución es hacerlo en samba ..

ninguno de los acl_xattr o acl_tdb funciona correctamente bajo dicha configuración, en bsd usan el vfs_zfsacl

a través de libsunacl que parece un traductor de zfs2bsd

Mi pregunta puede ser tonta, pero quiero tener claro si tenemos soporte acl o no. He creado el servidor mínimo VBox ubuntu 12.04 LTS, luego instalé ubuntu-zfs, creé los comandos pool w

Historia de 'mypool':
2013-05-05.15: 12: 49 zpool create -f mypool / dev / disk / by-id / ata-VBOX_HARDDISK_VB88a04e0d-d8d1e7a4

Historia de 'tanque':
2013-04-30.13: 44: 54 zpool crear tanque / root / vol1
2013-05-01.00: 13: 33 zfs set aclinherit = tanque de paso
2013-05-05.13: 50: 14 zfs establecer dedup = en el tanque

el tanque soporta setfacl sin problema
mypool NO lo hace y dice que la operación no es compatible.

Quiero usar zfs con samba y necesito controlar el acceso de múltiples usuarios a las carpetas. como eso
root @ server : ~ # setfacl -mg: USERS : --- test4v007 /

Quiero implementar el parche richacls para ZFS, pero como no tengo mucha experiencia con ZFS, sería bueno que uno de los desarrolladores de ZFSonLinux pudiera proporcionar algo de ayuda (principalmente en forma de sugerencias y discusiones).

Me gustaría darle un golpe a esto ...

@behlendorf : ahora que tiene una versión estable del sistema de archivos, ¿tenemos una escala de tiempo sólida para cuando esto

Queremos avanzar en el trabajo con la implementación de nuestros servidores NAS de almacenamiento de perfiles con Samba, pero no tener ACL puede significar que tengamos que seguir con FreeBSD, lo que realmente no queremos hacer, ya que toda nuestra base de experiencia es con Linux.

Espero que no sea un tema completamente diferente.
¿Ha probado Debian kFreebsd?

Es casi como una especie de Linux ...

@sopmot - Ya sabes, lo miré antes y lo

Buen grito, gracias por guiarme por el camino correcto. Disculpas por la mala educación.

Sigo mirando kfreebsd, y me falta iscsi, nfsv4 y un
equivalente a la virtualización kvm. Me tomé en serio su uso como root.
hasta que esas deficiencias se hicieron evidentes
El 19 de mayo de 2013 a las 9:50 a. M., "Tamas Papp" [email protected] escribió:

Espero que no sea un tema completamente diferente.
¿Ha probado Debian kFreebsd?

Es casi como una especie de Linux ...

-
Responda a este correo electrónico directamente o véalo en Gi
.

También me encantaría que se abordara este tema. Desafortunadamente, tengo poco tiempo en estos días (además, no sé una mierda sobre cosas de bajo nivel / kernel), así que no puedo hacer mucho para ayudarme a mí mismo :( Realmente, aunque solo estoy buscando una buena manera de hacer cumplir ciertos permisos para archivos nuevos en ciertos directorios; a menudo coloco archivos en una carpeta disponible públicamente y sería bueno si pudieran configurarse automáticamente con permisos relajados, ya que realmente no quiero configurar mi umask en algo tan liberal para la mayoría de los archivos que creo, que terminan en mi carpeta de inicio. En OSOL / FreeBSD haría esto usando NFSv4 ACL, aunque estoy abierto a mejores soluciones si alguien tiene alguna idea. La única otra cosa que puedo pensar de está ejecutando un cronjob que establece recursivamente los permisos en los directorios relevantes cada media hora o algo así, ¡pero esto es tan desagradablemente poco elegante!

Para su información, para que la gente no cometa el mismo error que yo, Debian kFreeBSD es excelente para el soporte de ZFS, pero las ACL aún no funcionan desde el área de usuario, solo obtiene "Función no implementada"; consulte el error de Debian: http: // bugs.debian.org/cgi-bin/bugreport.cgi?bug=607573

@iamacarpet Puede suceder tan pronto como alguien que necesite esta funcionalidad tenga tiempo para trabajar en ella. Actualmente, los principales impulsores del proyecto no utilizan mucho las ACL, por lo que se encuentran al final de la lista de prioridades. Pero no hay nada que impida que alguien que necesita este apoyo se lance y lo haga antes. Lo siento, pero es solo la realidad de la situación.

Hola,

Usamos zfsonlinux en un dispositivo de respaldo y creemos que las ACL son importantes para propósitos de integración. Se necesitan algunas operaciones comunes, como cambiar los permisos en un volumen compartido ZFS desde una computadora con Windows.

¿ACL todavía está en la hoja de ruta?

Gracias.

@ n1mh Está programado para la versión 0.8.0.

Gracias a @maxximino se ha implementado el soporte para Posix ACL. Abrí la solicitud de extracción # 1809 con una versión casi final del parche que está lista para pruebas más amplias. Pasa limpiamente la sección ACL de Posix Test Suite y no tenemos conocimiento de ningún problema pendiente.

Para aquellos que deseen esta funcionalidad, sería muy útil si pudiera probar el parche propuesto con una carga de trabajo realista. Verifique que se comporte como esperaría en su entorno. Las ACL de Posix están deshabilitadas de forma predeterminada, pero se pueden habilitar configurando la propiedad _acltype_ en el conjunto de datos.

zfs set acltype=posixacl pool/dataset

Las ACL Posix de estilo Linux se han implementado como xattr y se han fusionado en master. Se almacenan independientemente de las ACL nativas de NFS y no entrarán en conflicto. Se ha agregado la nueva propiedad acltype del conjunto de datos para habilitar esta funcionalidad. Para obtener el mejor rendimiento, se recomienda encarecidamente que establezca tanto acltype = posixacl como xattr = sa . Para obtener más detalles, consulte la página de manual actualizada:

       acltype=noacl | posixacl

           Controls  whether  ACLs  are  enabled and if so what type of ACL to
           use.  When a file system has the acltype property set to noacl (the
           default)  then  ACLs are disabled.  Setting the acltype property to
           posixacl indicates Posix ACLs should be used.  Posix ACLs are  spe-
           cific  to  Linux  and are not functional on other platforms.  Posix
           ACLs are stored as an xattr and therefore will  not  overwrite  any
           existing ZFS/NFSv4 ACLs which may be set.  Currently only posixacls
           are supported on Linux.

           To obtain the best performance  when  setting  posixacl  users  are
           strongly encouraged to set the xattr=sa property.  This will result
           in the Posix ACL being stored more efficiently on disk.  But  as  a
           consequence of this all new xattrs will only be accessable from ZFS
           implementations which support the xattr=sa property.  See the xattr
           property for more details.