Samba, ACLs do Windows e bit executável indesejado

1

Eu configurei o Samba com suporte a ACL em um servidor LTS do Ubuntu 18.04 e estou enfrentando a seguinte situação.

Aqui está o smb.conf content:

[global]
   # naming
   workgroup = WORKGROUP
   server string = %h server (Samba, Ubuntu)

   # networking
   disable netbios = yes
   local master = no
   domain master = no
   preferred master = no

   # domain accounts
   security = ADS
   realm = EXAMPLE.COM
   encrypt passwords = yes
   invalid users = root

   idmap config *:backend = tdb
   idmap config *:range = 70001-80000

   template shell = /bin/bash

   winbind nss info = rfc2307
   winbind use default domain = yes
   winbind rpc only = yes
   winbind cache time = 10

   vfs objects = acl_xattr
   map acl inherit = yes
   acl group control = yes
   store dos attributes = no

   # logging
   log file = /var/log/samba/log.%m
   max log size = 1000

   # permissions
   create mode = 0644
   directory mode = 0755
   inherit acls = yes
   map archive = no

   # printers
   load printers = no

   # veto files
   veto files = /._*/.DS_Store/

[All Users]
   comment = All Home Directories
   path = /home/EXAMPLE
   browseable = yes
   read only = no
   valid users = @dl_acc_ro @dl_acc_rw

Do macOS Sierra, conecto-me a um compartilhamento de samba com smb://myserver.com/test . Então eu abro um terminal e $ cd /Volumes/test e finalmente crio um arquivo com $ touch xxx .

Aqui está a saída de $ ls -l no meu Mac:

$ ls -l
-rwx------  1 gregory  staff  0 Sep 26 20:00 xxx

E agora no próprio servidor:

$ ls -l
-rwxrwxr-x+ 1 gregory utilisa. du domaine 0 Sep 26 18:00 xxx

E ACLs:

$ getfacl /home/EXAMPLE/gregory
getfacl: Removing leading '/' from absolute path names
# file: home/EXAMPLE/gregory
# owner: gregory
# group: utilisa.0du0domaine
user::rwx
group::r-x
other::r-x


$ getfacl /home/EXAMPLE/gregory/xxx
getfacl: Removing leading '/' from absolute path names
# file: home/EXAMPLE/gregory/xxx
# owner: gregory
# group: utilisa.0du0domaine
user::rwx
user:gregory:rwx
group::r-x
group:utilisa.0du0domaine:r-x
mask::rwx
other::r-x

Como você pode ver, o arquivo normal criado por touch tem o bit executável definido. Existe uma maneira de evitar esse comportamento? Eu gostaria que arquivos regulares criados através do Samba tivessem 0644 de permissões.

Para o registro, eu testei de uma estação de trabalho Linux e ele exibe o mesmo comportamento, o que me faz acreditar que tudo está acontecendo no lado do servidor Samba.

    
por Gregory Pakosz 26.09.2018 / 20:14

2 respostas

3

No manual do Samba:

Consequently, there is no use for any of the three Unix executable bits that are present on a file in a Samba disk share. DOS files, however, have their own attributes that need to be preserved when they are stored in a Unix environment: the archive, system, and hidden bits. Samba can preserve these bits by reusing the executable permission bits of the file on the Unix side—if it is instructed to do so. Mapping these bits, however, has an unfortunate side effect: if a Windows user stores a file in a Samba share, and you view it on Unix with the ls -al command, some of the executable bits won't mean what you'd expect them to.

Como desativá-lo? Seguindo o manual:

Three Samba options decide whether the bits are mapped: map archive, map system , and map hidden. These options map the archive, system, and hidden attributes to the owner, group, and world execute bits of the file, respectively. You can add these options to the [data] share, setting each of their values as follows:

 [data]
    map archive = no
    map system = no
    map hidden = no

Você também pode desativar o bit executável usando o % sinalizadorstore dos attributes .

    
por 29.09.2018 / 10:58
0

Veja as várias configurações de mask em smb.conf . Por exemplo. create mask , directory mask , ...

Por exemplo, esses masks podem ser influenciados pelas opções de montagem no cliente, o que também pode ser útil para examinar os detalhes.

    
por 29.09.2018 / 10:50