Início / server / Perguntas / 765104
Accepted
user121391
Asked: 2016-03-22 06:23:39 +0800 CST

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

  • 772

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

Quero criar um diretório compartilhado com os seguintes objetivos: um usuário (digamos alice) deve ser capaz de criar e modificar arquivos, mas não 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 alicevisualizar a guia Segurança dos arquivos recém-adicionados no Windows Explorer, ela poderá conceder a si mesma direitos de acesso total e excluir o arquivo posteriormente, mesmo que não tenha Codireitos.

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

Edit: A saída de lsparece 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 lspara o próprio diretório:

# /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 é 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 CIFS são definidas para permitir acesso total a todos, portanto, apenas a permissão de arquivo deve ser aplicada.

Atualizar:

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

windows

2 respostas

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

    • Em casos de negação de permissões ou quando falta uma permissão de acesso para um arquivo, 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 e permite que o superusuário modifique os arquivos para fins de recuperação.
    • As ACLs baseadas em rascunho 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 possui dois tipos de ACEs que afetam a verificação de acesso: ALLOW e DENY
    • O proprietário de um arquivo recebe a permissão write_acl incondicionalmente, 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 concedia a um usuário acesso a um arquivo ou diretório, esse usuário ainda poderia 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 as acls triviais de acordo com as necessidades (use o modo de negação) e adicionar 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 foi concedida, ela não pode ser negada por uma entrada de negação de ACL subsequente no mesmo conjunto de permissões de ACL.

    Se você não tem ideia do que é OmniOS, mas esses documentos me ajudaram a entender o NFS ACL. Usamos Solaris com ZFS https://docs.oracle.com/cd/E53394_01/html/E54801/ftyxi.html#scrolltoc

    • 1
  2. Best Answer

    Depois de ignorar esse problema por uma semana, agora de repente funciona ... Não sei o que causou isso, mas funciona ... Tentei a sugestão deste blog , mas modifiquei para incluir AWcomo direitos. Então eu testei novamente, desta vez apenas com minhas regras de negação mais antigas (substituindo as novas completamente), que também funcionaram. Por fim, usei as primeiras configurações da minha própria pergunta, que nunca funcionaram, mas agora 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 antigo (e errado) comportamento.

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

    1. Aplique as seguintes regras ACL ao diretório e (herdado) 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 ZFS (isso é necessário para impedir que o proprietário modifique as ACLs, para obter detalhes, consulte a resposta de @embedded e a postagem de falha do servidor vinculada):

      /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 alteradas, 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 a si mesmos direitos adicionais. Esta solução funciona bem para a minha situação, mas posso ver duas pequenas desvantagens:

    • Você deve lembrar/documentar que alterou o nível de compartilhamento, se permissões adicionais devem ser definidas no futuro.
    • É possível que um usuário modifique o conteúdo dos documentos. Por exemplo, alicepode substituir caracteres ou linhas em um documento de texto. Acho que isso ocorre porque o aplicativo que uso precisa dos privilégios de acréscimo e gravação e não há ACL que verifique "somente gravação inicial" ou algo semelhante.
    • 1

relate perguntas