Estoy construyendo un servidor de respaldo usando Linux, ZFS y Samba. Todos los clientes, excepto yo, usarán Windows 10, por lo tanto, mi atención se centra en admitir Windows 10 correctamente, pero eso no significa que se deba permitir que los permisos en el lado de Linux sean inseguros (es decir, legibles y escribibles en todo el mundo).
Después de eliminar por error las ACL POSIX en todos los archivos, pensando que eran algo configurado inicialmente para permitir el acceso grupal, todos los permisos en los archivos en el lado de Windows se rompieron.
Esto se solucionó revisando cada opción en el manual y rehaciendo la configuración. Descubrí qué opciones configurar para obtener el comportamiento que deseo, es decir, configurar los permisos solo en el lado de Windows, mientras mantengo seguros los permisos de UNIX, sin embargo, hay Todavía hay 2 cosas que no entiendo sobre cómo Samba maneja los permisos de UNIX.
La configuración acl_xattr:ignore system acls = nohace que los permisos de UNIX se conviertan en entradas en las ACL de Windows (entradas CREADOR, GRUPO y TODOS), lo cual no quería; sin embargo, cuando se configura en yes, el propietario, el grupo y los permisos todavía parecen afectar los permisos en el lado de Windows. Samba todavía los aplica. Si un directorio tenía root:backup 0660permisos, entonces un usuario aleatorio Domain Userno tendrá acceso a ese directorio, aunque las ACL de Windows tuvieran una entrada para Domain Users. Cambiando el grupo desde backupdonde usersse usersasigna al grupo NT Domain Users, entonces funcionará. Claramente, los permisos de UNIX todavía se aplican.
¿Existe una configuración para hacer que las ACL de Windows veten el resto, es decir, si las ACL de Windows lo permiten Domain Users, se permitirán independientemente de lo que digan los permisos de UNIX? ¿O podría simplemente desactivar Samba usando los permisos de UNIX?
La otra pregunta es cómo almacena Samba los permisos de UNIX. En la nueva configuración que tenía inherit owner = yes. Esto pareció funcionar como se esperaba tanto en Windows como en UNIX, excepto cuando intenté cambiar el grupo de UNIX a otro. Inicialmente, el bit setgid se configuró en las acciones johncomo su grupo, pensando inherit ownerque solo afecta al propietario, no al grupo. Sin embargo, al eliminar el bit setgid de los recursos compartidos y cambiar el grupo a usersrecursivo, los inherit owner = yesnuevos archivos y directorios creados desde un cliente de Windows 10 todavía se creaban con el grupo john. En ninguna parte del árbol de directorios había un directorio con un grupo johnrestante. Intenté reiniciar mi cliente Windows y el servidor Samba por si acaso, pero eso no cambió nada.
¿Samba almacena los permisos de UNIX en otro lugar, por lo que mi cambio del grupo UNIX directamente desde el sistema de archivos no afecta al grupo rastreado por Samba? ¿O cuál podría ser la causa de que Samba todavía use este grupo antiguo para archivos y directorios nuevos?
A continuación puede encontrar las opciones potencialmente relevantes de la configuración de Samba versión 4.7.6. Si se necesita más información, hágamelo saber.
[global]
access based share enum = yes
acl group control = no
acl map full control = yes
acl_xattr:ignore system acls = yes
acl_xattr:default acl style = windows
create mask = 0775
directory mask = 0775
dos filemode = yes
dos filetime resolution = no
dos filetimes = yes
ea support = no
force create mode = 0600
force directory mode = 0600
force unknown acl user = no
guest account = nobody
guest ok = no
guest only = no
inherit acls = no
inherit owner = unix only
inherit permissions = no
invalid users = root
map acl inherit = yes
map archive = no
map hidden = no
map readonly = no
map system = no
map to guest = never
nt acl support = yes
obey pam restrictions = no
read only = yes
restrict anonymous = 2
security = user
server role = active directory domain controller
store dos attributes = yes
unix extensions = yes
vfs objects = dfs_samba4 acl_xattr shadow_copy2
[backups]
create mask = 0660
directory mask = 0770
ea support = yes
path = /mnt/pool/backups
read only = no
Respuesta1
¿Samba almacena los permisos de UNIX en otro lugar, por lo que mi cambio del grupo UNIX directamente desde el sistema de archivos no afecta al grupo rastreado por Samba? ¿O cuál podría ser la causa de que Samba todavía use este grupo antiguo para archivos y directorios nuevos?
Sólo he podido encontrar respuesta a esta segunda pregunta. Durante mi experimentación, inherit owneren un momento quise saber cuáles eran los valores que estaban almacenados como parte de las ACL de NT, así que inspeccioné un directorio y samba-tool ntacl get /path/to/dir, para mi sorpresa, vi el antiguo GID como el valor del archivo group_sid. Y como ya no tenía ninguna otra referencia al antiguo GID en ningún otro lugar del sistema de archivos, esta parece ser la causa probable de que Samba conserve el antiguo grupo de UNIX, especialmente porque cada vez que establezco heredar propietario en unix onlyo no, no tendrá el antiguo grupo UNIX. Entonces, aparentemente establecer inherit owneren yes(es decir unix and windows), hace que Samba establezca el grupo UNIX en el grupo almacenado en las ACL de NT.
Todavía me encantaría recibir una respuesta a la primera pregunta, pero encontré una solución al encontrar una manera deasignar el grupo NT Domain Usersa mi grupo UNIX preferidoy establecer los permisos de otros en 0 a través de ACL POSIX: setfacl -Rm d:o:---,o:--- /my/share.