Compartilhada, leitura-escrita, árvore de diretórios de fotos, para usuários normais

Question

Ou seja. o que eu quero é o equivalente em Linux do Windows Public/Pictures .

O problema é que o gerenciador de arquivos do Linux Nautilus não aplica as ACLs padrão quando você move um arquivo para uma pasta / diretório (nem o bom set-group-id). Nem mesmo no caso esperado, em que o arquivo está apenas em um diretório por vez, ou seja, ele também não tem link físico em outro diretório.

Portanto, arrastar as fotos de uma câmera conectada não funciona, mesmo com uma ACL padrão. Outros usuários poderão ler as fotos, mas não poderão escrever para elas. Eles são mostrados com um cadeado no gerenciador de arquivos.

Curiosamente, não está usando rename() neste caso, porque a movimentação cruza os sistemas de arquivos. O Nautilus está apenas fornecendo semânticas consistentes neste caso, aplicando novamente as permissões do arquivo de origem: trollface:.

Infelizmente, lembrei-me disso tarde demais, depois de me cansar de instruir outros usuários sobre como usar o Digikam. (O Digikam funcionou, porque excluir fotos do cartão é uma operação separada. Então as fotos são necessariamente copiado , em vez de movido). Eu os instruí a escrever notas sobre o uso do gerenciador de arquivos. Suspiro.

Então, sei que esse não é o uso esperado, ou seja, computadores com vários usuários não foram realmente atendidos. Mas existe alguma maneira sensata de configurar isso para meus colegas usuários?

Estou descontando qualquer método que seja mais difícil de lembrar para as pessoas (mais ou menos um mês) do que o do gerenciador de arquivos. Isso exclui o Digikam; ele tem muitas escolhas sem sentido e, em seguida, exige confirmação antes de remover as imagens do cartão, como se toda essa operação estivesse cheia de perigos. (Também infelizmente, com o nosso software, obtemos um popup "importar fotos usando o Digikam" que não funciona).

Também estou excluindo qualquer gerenciador de fotos que não possa salvar os nomes dos álbuns (incluindo uma data) no sistema de arquivos. Se você não pode exportar para o Digikam, então você não é confiável o suficiente para me fazer importar do Digikam!

Ambiente:

• Linux
• Debian
• Área de trabalho padrão do GNOME

Answer 1

Eu vi outra abordagem sugerida nos comentários de bug do Docker. Há um sistema de arquivos FUSE que altera as permissões. Há um impacto no desempenho apenas com o uso do FUSE, mas O FUSE não é tão ruim quanto você imagina . Confira o link

Exemplo de linha para /etc/fstab , que permite aos usuários que foram adicionados ao grupo photos :

/home/photos /home/photos fuse.bindfs nofail,allow_other,force-group=photos,perms=g+wX

Também pode ser possível endereçar algumas linhas de código. Infelizmente não é um exercício completamente trivial. O segundo link abaixo funcionaria se você não se importa de quebrar em novas linhas (ou barras invertidas, aparentemente?) Em nomes de arquivos.

link

link

    

Answer 2

Esqueci outra coisa. Se não posso escrever em um arquivo, ainda posso removê-lo e substituí-lo. E essa é exatamente a maneira correta de salvar um arquivo . (Porque você tem que fsync() antes de ter um arquivo durável, que você pode substituir com segurança o antigo com).

Parece funcionar bem, você só tem que ignorar os cadeados :). Por exemplo. Posso rodar fotos copiadas por outros usuários.

EXCLUSÃO DE RESPONSABILIDADE : o Digikam parece atualizar os metadados da foto incorretamente. Então, isso falhará silenciosamente (: trollface2 :), deixando o banco de dados (metadados) inconsistente. Felizmente eu não me importo em fazer tagging no momento, mas essa é outra daquelas pequenas armadilhas para eu tropeçar mais tarde.

    

Answer 3

Amusingly it isn't using rename() in this case, because the move crosses filesystems. Nautilus is just providing consistent semantics in this case by re-applying permissions form the source file :trollface:.

Eu gostaria que esse fosse o único problema. Mas eu recebo as mesmas permissões efetivas quando copiando também. É verdade que a ACL padrão é aplicada, se eu verificar com getfacl . No entanto, ele também mostra uma "máscara" e que a ACL padrão aplicada é efetivamente desativada pela máscara.

Para até mesmo fazer o copiar funcionar ... você não precisa necessariamente de uma ACL padrão; historicamente, você confiaria no padrão Grupos privados de usuários , com o diretório compartilhado sendo marcado set-GID.

Infelizmente, o GNOME moderno não foi desenvolvido para sistemas multiusuários e há dois problemas que o quebraram.

1. udisks usa a antiga máscara unix 0022 ao montar sistemas de arquivos FAT, como o cartão SD de uma câmera, em nome dos usuários .
2. bug systemd (ou "RFE" lol): Permitir a seleção de "systemd --user" umask .

Por exemplo, quando você usa cp para copiar uma imagem do cartão SD, o cp copia o modo original, limitado pela umask atual. Por isso, é afetado por ambos os problemas. (Pode ser afetado pelo primeiro problema porque você executou cp dentro do serviço systemd --user conhecido como gnome-terminal-server.service ).

(Outro aspecto dessa situação é que o Debian implementou o UPG desde o início, mas quebrou o umask quando implementou o PAM. Embora esse problema seja muito mais simples de se trabalhar usando a configuração do PAM, talvez ilustre uma falta de demanda, e talvez tenha contribuído para a falta de consciência sobre a UPG).

O problema 2 quebra o uso tradicional do UPG, que depende de um umask de 0002 e um diretório compartilhado set-GID.

No entanto, quando você usa uma ACL padrão no diretório compartilhado, o umask é efetivamente sobreposto, e o problema 1 é o "único" problema.