O usuário do Windows pode sobrescrever as permissões ACL do NFSv4 / Solaris dos arquivos no compartilhamento CIFS / SMB (conceder acesso total a si mesmo), como evitar isso?

Question

Eu tenho o compartilhamento de arquivos SMB / CIFS configurado em um servidor OmniOS com o módulo de kernel do Solaris que usa ACLs NFSv4 que devem funcionar corretamente com clientes Windows.

Eu quero criar um diretório compartilhado com as seguintes metas: um usuário (digamos alice ) deve ser capaz de criar e modificar arquivos, mas não de excluí-los. Também a criação de subdiretórios deve ser evitada. O acesso de leitura deve ser permitido.

Eu tentei a seguinte ACL, que basicamente funciona:

/usr/bin/chmod A=\
user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
/pool/share

Mas se alice exibir a guia Segurança dos arquivos adicionados recentemente no Windows Explorer, ela poderá conceder a si mesma direitos de acesso completos e excluir o arquivo depois, mesmo que ela não tenha Co de direitos.

Como explicar esse comportamento? E como posso alterá-lo para que as ACLs não possam ser modificadas?

Editar: a saída de ls parece ser normal:

# /usr/bin/ls -v
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    0:user:root:read_data/write_data/append_data/read_xattr/write_xattr
        /execute/delete_child/read_attributes/write_attributes/delete
        /read_acl/write_acl/write_owner/synchronize:inherited:allow
    1:user:alice:read_data/write_data/append_data/read_xattr
        /write_xattr/execute/read_attributes/write_attributes/read_acl
        /synchronize:inherited:allow

# /usr/bin/ls -V
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    user:root:rwxpdDaARWcCos:------I:allow
    user:alice:rwxp--aARWc--s:------I:allow

Saída de ls para o diretório em si:

# /usr/bin/ls -Vd
drwx------+  3 root     root           4 2016-03-21 .
 user:root:rwxpdDaARWcCos:fd-----:allow
user:alice:rwx---a-R-c--s:-------:allow
user:alice:rwxp--aARWc--s:f-i----:allow

# /usr/bin/ls -vd
drwx------+  3 root     root           4 2016-03-21 .
    0:user:root:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /delete_child/read_attributes/write_attributes/delete/read_acl
        /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
    1:user:alice:list_directory/read_data/add_file/write_data
        /read_xattr/execute/read_attributes/read_acl/synchronize:allow
    2:user:alice:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /read_attributes/write_attributes/read_acl/synchronize
        :file_inherit/inherit_only:allow

O sistema de arquivos do compartilhamento é o ZFS. As propriedades não-padrão mais interessantes são as seguintes:

NAME        PROPERTY        VALUE          SOURCE
pool/share  type            filesystem     -
pool/share  compression     lz4            inherited from pool
pool/share  atime           off            local
pool/share  aclmode         restricted     local
pool/share  aclinherit      passthrough    local
pool/share  version         5              -
pool/share  utf8only        on             -
pool/share  normalization   formD          -
pool/share  casesensitivity insensitive    -
pool/share  nbmand          on             local
pool/share  sharesmb        name=testshare local

As permissões de compartilhamento do CIFS estão definidas para permitir acesso total a todos, portanto, somente a permissão de arquivo deve ser aplicada.

Atualização:

Este tópico é muito parecido com o meu problema, embora a solução de reduzir as ACLs em /pool/share/.zfs/shares/testshare para modify_set para todos (ou negar permissões de exclusão específicas aos usuários) pareça não funcionar no meu caso e não sei por quê.

    

Answer 1

Depois de ignorar este problema por uma semana, agora de repente funciona ... Eu não sei o que causou isso, mas funciona ... Eu tentei a sugestão de este blog , mas modificou-o para incluir AW como direitos. Então eu testei de novo, desta vez apenas com as minhas antigas regras de negação (sobrescrevendo as novas completamente), isso também funcionou. Por fim, usei as primeiras configurações da minha própria pergunta, que nunca funcionaram, mas agora elas funcionaram.

Depois de mais alguns testes, acho que foi porque o serviço SMB não foi reiniciado antes e as ACLs de compartilhamento não foram reconhecidas corretamente. Mudá-los era a única maneira de restaurar o comportamento antigo (e errado).

Portanto, para referência futura, a solução é definir as permissões normais nos próprios arquivos e não permitir permissões Co no nível de compartilhamento:

1. Aplique as seguintes regras de ACL ao diretório e (herdadas) a todos os arquivos recém-criados:

   /usr/bin/chmod A=\
   user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
   user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
   user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
   /pool/share
   

2. Aplique as seguintes regras de ACL ao diretório de compartilhamento oculto do conjunto de dados do ZFS (isso é necessário para impedir que o proprietário modifique as ACLs, para obter detalhes, consulte a resposta do @ embedded e a postagem vinculada do servidor):

   /usr/bin/chmod A=\
   user:root:full_set:-------:allow,\          # root has full access
   everyone@:modify_set:-------:allow \        # anyone else cannot modify permissions
   /pool/share/.zfs/shares/testshare
   

3. Reinicie o servidor SMB (necessário para atualizar as ACLs de compartilhamento alterado, consulte este tópico ):

   svcadm restart svc:/network/smb/server:default # restart service
   svcs -xv svc:/network/smb/server:default       # check if the startup date has changed
   

Agora, novos arquivos podem ser criados e gravados, mas não excluídos, e também os usuários do Windows não podem conceder direitos adicionais. Esta solução funciona bem para minha situação, mas posso ver duas pequenas desvantagens:

• Você precisa lembrar / documentar que alterou o nível de compartilhamento, se permissões adicionais precisarem ser definidas no futuro.
• É possível que um usuário modifique o conteúdo dos documentos. Por exemplo, alice pode sobrescrever caracteres ou linhas em um documento de texto. Acho que isso acontece porque o aplicativo que eu uso precisa dos privilégios de anexar e escrever e não há nenhum ACL que verifique "somente gravação inicial" ou similar.

Answer 2

IMHO tudo fica muito confuso se você remover os acls triviais para usuário, grupo, todos. Coisas a considerar:

• Em casos de permissões de negação ou quando uma permissão de acesso para um arquivo está ausente, o subsistema de privilégios determina qual solicitação de acesso é concedida para o proprietário do arquivo ou para o superusuário. Esse mecanismo evita que os proprietários de arquivos sejam bloqueados em seus arquivos e permite que o superusuário modifique arquivos para fins de recuperação.
• As ACLs baseadas em rascunho do POSIX usam uma única entrada para definir quais permissões são permitidas e quais permissões são negadas. O novo modelo de ACL tem dois tipos de ACEs que afetam a verificação de acesso: ALLOW e DENY
• O proprietário de um arquivo recebe incondicionalmente a permissão write_acl, mesmo que a permissão seja explicitamente negada.
• Se você alterar as permissões do arquivo, a ACL de um arquivo será atualizada de acordo. Além disso, se você remover uma ACL não-trivial que concede a um usuário acesso a um arquivo ou diretório, esse usuário ainda poderá ter acesso ao arquivo ou diretório devido aos bits de permissão do arquivo ou diretório que concedem acesso a um grupo ou a todos

Portanto, minha abordagem é modificar os acls triviais de acordo com as necessidades (use o modo negar) e adicionar os acls não-triviais para todos os casos de uso especiais. Tenha isso em mente também:

• Depois que uma permissão de permissão for concedida, ela não poderá ser negada por uma entrada de negação de ACL subsequente no mesmo conjunto de permissões da ACL.

Se você não tem ideia do que é o OmniOS, mas esses documentos me ajudaram a entender o NFS ACL. Nós usamos o Solaris com o ZFS link