facl, setfacl, compartilhamento de diretório, por que o cp coloca as permissões do arquivo original na máscara facl? Não deveria ' esse ser um comportamento cp -p?

Os usuários neste sistema são cuidadosos e têm suas umasks definidas para o 0077 muito privado. No entanto, os usuários gostariam de ter diretórios específicos de grupo, onde arquivos podem ser copiados de modo a compartilhá-los explicitamente apenas entre outros membros do grupo. Pode haver vários desses diretórios de compartilhamento, embora cada um seja específico para um grupo.

Definir o sticky bit de grupo em um determinado diretório a ser usado para compartilhamento não é suficiente. Embora definir o sticky bit faça com que a propriedade do grupo seja correta em arquivos colocados no diretório, as permissões em tais arquivos são frequentemente definidas de forma que os arquivos não possam ser lidos ou editados, ou seja, não podem ser realmente compartilhados. Eles apenas aparecem na lista de diretórios. Isso ocorre porque alguns usuários não pensam ou não sabem como fazer manualmente o ajuste de permissões de grupo necessário para permitir leitura e gravação. Podemos dar um tempo a eles porque os usuários não são administradores, afinal. acls pode ser usado para especificar que um determinado grupo tem acesso aos arquivos no diretório de compartilhamento, independente de quais seriam as permissões do grupo sem acls. Essa é a solução perfeita, mas não está funcionando muito bem.

A seguir, o grupo compartilhado é “customer_gateway” e o usuário de exemplo tentando compartilhar um arquivo é “svw”. Como pode ser visto na transcrição, o usuário svw é um membro do grupo customer_gateway. O diretório onde o compartilhamento deve ocorrer também é chamado de “customer_gateway /”

O seguinte usa acls. Eu defino as permissões de grupo, as permissões de grupo padrão, a máscara e a máscara padrão. Funciona bem para arquivos criados no diretório ou para arquivos movidos para lá via cat (ou tar), mas, estranhamente, não para arquivos que “cp” ed lá:

# rm -r customer_gateway/ # umask 0077 # cat ~/script1 mkdir customer_gateway chown :customer_gateway customer_gateway/ chmod g+rwx customer_gateway/ setfacl -m group:customer_gateway:rwX customer_gateway/ setfacl -m d:group:customer_gateway:rwX customer_gateway/ setfacl -m m::rwX customer_gateway/ setfacl -m d:m::rwX customer_gateway/ getfacl customer_gateway cd customer_gateway touch cga cat << EOF > cgb c g b EOF ls -l # . ~/script1 # file: customer_gateway # owner: root # group: customer_gateway user::rwx group::rwx group:customer_gateway:rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:customer_gateway:rwx default:mask::rwx default:other::--- total 4 -rw-rw----+ 1 root root 0 Mar 2 20:43 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb # su - svw /home/svw/bin:/usr/local/bin:/usr/bin:/bin (note umask is 0077) > cd /share/customer_gateway/ > groups svw adm dip video plugdev google-sudoers customer_gateway > cat >> cga e f g > cat > cgc c g c > ls -l total 12 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc > ls ~/dat ta tb tc > cat ~/dat/ta > ta > cp ~/dat/tb tb > ls -l total 20 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc -rw-rw----+ 1 svw svw 4 Mar 2 20:45 ta -rw-------+ 1 svw svw 4 Mar 2 20:45 tb > getfacl ta # file: ta # owner: svw # group: svw user::rw- group::rwx #effective:rw- group:customer_gateway:rwx #effective:rw- mask::rw- other::--- > getfacl tb # file: tb # owner: svw # group: svw user::rw- group::rwx #effective:--- group:customer_gateway:rwx #effective:--- mask::--- other::--- > 

O que isso mostra é que quando um arquivo é criado no diretório, ele recebe as permissões padrão e pode ser compartilhado. Mas os usuários nem sempre criam seus arquivos lá, normalmente eles os copiam lá.

Mas fazer uma cópia é a mesma coisa, porque para fazer uma cópia devemos primeiro criar um novo arquivo. Estamos falando de uma cópia simples aqui, não uma cópia de permissões de preservação. É o mesmo que a seguinte forma, que, aliás, funciona e copia um arquivo que poderá ser compartilhado no diretório independente de suas permissões de grupo originais:

cat < data.in > shared/data.out 

funciona bem, canalizar através do tar também funciona, mas o formulário

cp data.in shared/data.out 

falha. O cat arquivo ed obtém a máscara padrão e as permissões padrão. O arquivo cp ed preserva suas permissões na máscara acl e as permissões do grupo, como se fosse a cp -p (mas não era) e, portanto, as permissões efetivas são lidas como o arquivo original, não como as acls foram definidas.

Como uma segunda tentativa, executei este experimento com o group sticky bit, chmod g + rwxs, junto com o facl ch anges e obtiveram exatamente os mesmos resultados. Embora as listas de diretórios sejam mais bonitas devido à propriedade do grupo exibida para todos os arquivos compartilhados. Eu também o executei com apenas o bit sticky de grupo sendo definido, sem o setfacl. Também teve o mesmo resultado para arquivos copiados (então facls parecem bastante inúteis para um diretório onde os arquivos são copiados para serem compartilhados).

Com base e com que justificativa o facls do linux distingue entre diferentes formas de criando dados? Por que forçar o cp a preservar as permissões quando não foi dito para fazer isso? Qual motivo justificaria a confusão causada por esta distinção entre cat e piping through tar funcionando, mas cp não funcionando? Estou perdendo um encantamento mágico que faria essa distinção evaporar?

Este resumo está correto: facls permitirá que você ultrapasse a propriedade para compartilhar arquivos, tornará as permissões mais permissivas do que o umask ao “criar” arquivos, a menos que a criação seja devido ao comando cp e por um bom motivo porque … por quê?

Comentários

• Qual sistema operacional (distribuição e versão do Linux) e qual sistema de arquivos você está usando? Seria correto fazer as pessoas usarem cat, talvez por meio de um shellscript dedicado para este propósito?
• Você pretende que qualquer usuário do grupo possa modificar ou excluir qualquer arquivo, ou apenas o criador deve ter tais permissões? Em outras palavras, apenas permissões de leitura (e talvez permissões de execução) para o outros usuários.
• Debian 10. Como a criação de arquivos funciona, eu ‘ tenho enviado cópias pelo tar. Eu ‘ empacotarei isso como um comando proj_cp em / usr / local / bin. No entanto, se um usuário tiver que usar um comando de cópia especial, poderá simplesmente ir com o sticky bit de grupo sem facls e definir as permissões. Eu quero saber como definir as acls para que cat tar e cp funcionem.Eu ‘ estou pensando que há um problema com acls com cp, pois eles estão fazendo o comportamento cp -p em vez do comportamento cp. Eu ‘ estou ansioso para ouvir os especialistas em permissões.
• Compartilhamento de grupo é um problema recorrente com variações, como você destacou. Nesse caso, os desenvolvedores de software têm acesso ao diretório de versão de teste. É deles para se sujar. Eles podem trabalhar nesse diretório, enviar, puxar, instalar no ambiente virtual, etc. O problema surge quando eles copiam coisas de outra área em que estiveram trabalhando e suas umasks não estão configuradas com permissões de grupo. É confuso para eles porque a criação e cópia de arquivos pelo tar funciona bem. Também é engraçado que eu tenha que dar a eles um script de cópia que faz exatamente o que o cp faz. ‘ acls ‘ eles são mágicos, eu digo LOL
• Não sou especialista em permissões, mas espero que minhas perguntas e suas respostas podem ajudar os especialistas a fornecer respostas relevantes.