Posso portar permissões de usuário em vários computadores para um disco rígido externo ext4?

16

Eu tenho uma unidade de disco externa USB 3 (capacidade de 2TB) que provavelmente será movida de máquina para máquina. O disco tem uma tabela de partição GUID e uma partição ext4. Não consigo gravar no disco a menos que eu eleve o processo ( sudo ).

A partir de agora eu estou pensando em tentar um ou ambos dos seguintes e gostaria de saber os contras de cada -

  1. chmod 777 /mnt/externalDrive
  2. chown nobody:nogroup /mnt/externalDrive

Se eu der 777 permissão e user1 (UID: 1005) gravar nele e depois mover o disco para outro computador em que user7 é UID: 1005, o que acontece? O usuário7 se torna o proprietário do arquivo nesse computador? Parece-me que periodicamente terei que executar chown -R nobody:nogroup /mnt/externalDrive no disco.

Algum do que estou considerando é uma prática ruim óbvia? O disco provavelmente conterá vídeos, músicas e fotos, e nada disso precisa ser protegido como alguns dados financeiros.

    
por Lord Loh. 24.04.2014 / 00:50

4 respostas

18

Esse é o problema com sistemas multiusuários, especialmente se você tiver mais de um deles. ;) Não há nenhuma maneira realmente de fazer o que você quer. Abordagens que vêm à mente seriam

  • ter o mesmo UID para sua conta em todas as máquinas que você estiver usando sua unidade externa (na verdade, não é viável, pois provavelmente nem todas as máquinas estão sob seu controle)
  • usando um sistema de arquivos sem saber do proprietário / conecpt do grupo (FAT ou NTFS vem à mente, mas… aaah, no)

A abordagem mais eficaz seria voltar às práticas comuns. Na maioria (pelo menos) dos sistemas Linux, existem alguns grupos que têm geralmente GIDs comuns. No exemplo, seria users , que tem GID 100 na maioria das distros Linux. Se você conseguisse ter sua respectiva conta de usuário nesse grupo, poderia

  1. cria todos os arquivos e diretórios em sua unidade de propriedade desse grupo
  2. de alguma forma conseguem ter permissões de grupo apropriadas nesses arquivos e diretórios
  3. de alguma forma conseguem ter novos arquivos criados com resp. permissões.

Primeiro e segundo ponto são fáceis de realizar ( chown , chmod ). O terceiro ponto é um pouco mais complicado.

A parte "propriedade do grupo" é relativamente fácil: você pode definir o bit SGID em todos os diretórios da unidade. O bit SGID aplicado aos diretórios diz ao kernel para se comportar de uma maneira BSDish: O BSD faz com que todo arquivo / diretório criado sob um diretório específico pertencente ao grupo principal do processo crie o arquivo / diretório (como o Linux faz), mas pelo proprietário do diretório pai.

O bit de permissão é um pouco difícil. Permissões de arquivos / diretórios recém-criados são (entre outros) influenciados pelo umask , uma máscara de bits informando quais bits não serão definidos se não forem explicitamente declarados. Um valor comum de umask , por exemplo, é 022 , o que significa que os bits de gravação para »grupo« e »outros« normalmente não devem ser definidos. Você poderia alterar o seu umask para 002 , dizendo que você não quer que as permissões de gravação sejam limpas para o grupo, mas a desvantagem é que você não pode definir este valor baseado em diretório e geralmente não quer ter permissões de gravação para o seu grupo primário definido para cada arquivo criado.

Isso pode ser resolvido usando ACLs: em uma ACL, é possível definir um conjunto de permissões mask e default , que se aplica a todos os arquivos e diretórios criados dentro de um diretório com esse conjunto de ACLs. Então, uma possível solução do seu problema seria

  • certificando-se de que você é um membro de um grupo comum em todos os sistemas em que deseja usar sua unidade externa em
  • cria todos os arquivos e diretórios em sua unidade de propriedade desse grupo e define o bit SGID em todos os diretórios
  • altere a ACL de todos os diretórios para incluir uma máscara e permissões padrão que digam ao kernel para criar todos os novos arquivos / diretórios com permissões de gravação definidas para o grupo.

Veja setfacl(1) e acl(5) para mais detalhes.

    
por 24.04.2014 / 01:08
10

outra pergunta semelhante e o bindfs é sugerido lá :

mkdir /home/$user/sda1
bindfs -u $user -g $group /mnt/sda1 /home/$user/sda1

Os usuários do OSX sugerem a opção noowners mount descrita assim:

Ignore the ownership field for the entire volume. This causes all objects to appear as owned by user ID 99 and group ID 99. User ID 99 is interpreted as the current effective user ID, while group ID 99 is used directly and translates to ''unknown''.

    
por 12.10.2014 / 17:24
4

O proprietário e o grupo de um arquivo são armazenados como números. Portanto, o arquivo será de propriedade de uid = 1005, independentemente de qual usuário (ou nenhum) que esteja no sistema ao qual está conectado.

Alterar o usuário / grupo para ninguém não corrigirá seu problema. Então, somente o usuário nulo (ou membros do grupo de ninguém) teria permissão para acessar os arquivos.

Infelizmente, não acho que haja uma maneira de desabilitar as verificações de permissão no ext4. Veja, por exemplo, É possível desabilitar permissões de arquivos em um sistema de arquivos ext3 ou ext4?

    
por 24.04.2014 / 01:11
2

Andreas Wiese diz que se você tiver um ID de grupo comum em todos os hosts, poderá resolver o problema com setgid bit e ACL

Eu faço uma pergunta IDs de grupo pré-definidos nas distribuições Linux?

Após a própria pesquisa descobriu que tal grupo existe em todas as distros tocadas: sys group share id 3 no Debian, Ubuntu, RedHat, Fedora, CentOS, Suse, FreeBSD, OpenBSD, NetBSD, MacOSX, Solaris.

Com isso:

$ sudo chgrp -R sys /mnt/data/dir
$ sudo chmod -R g+s /mnt/data/dir
$ sudo setfacl -R -m g:sys:rwx /mnt/data/dir
$ sudo setfacl -R -d -m g:sys:rwx /mnt/data/dir

e sabor disso:

$ sudo adduser user sys

você user poderá ler / gravar qualquer arquivo em /dir .

A maioria das tarefas pode fazer setgid bit, mas infelizmente você geralmente tem pouco controle sobre umask . Então, o ACL é usado para fornecer uma solução completa.

Veja também:

por 01.04.2016 / 19:09