Tenho lido sobre a "parte pegajosa" e é quase o que eu quero... mas não exatamente.
Fundo
Estou gerenciando uma pequena instância do JupyterHub com três cursos e um instrutor para cada curso. Gostaria de ter uma pasta no servidor para envios de arquivos.
Os alunos (no jupyterhub-users
grupo) devem ser capazes de colocar seus próprios arquivos na pasta, mas não devem ser capazes de mover ou visualizar outros arquivos na pasta. Idealmente, eles devem manter a capacidade de mover ou editar seus próprios arquivos.
Os instrutores do curso (no jupyterhub-instructors
grupo) devem ter acesso total aos arquivos e pastas na submissions
pasta para que possam mover os envios dos alunos conforme acharem adequado.
Minha compreensão atual
Estou ciente do sticky bit… meu problema com ele é que ele deixa os outros instrutores incapazes de modificar o conteúdo da pasta. Existe uma versão do sticky bit que permite que o grupo edite a pasta? Nesse caso, posso definir ACLs de modo que jupyterhub-users
tenham rwx
permissões na pasta (permitindo que eles enviem arquivos para a pasta e vejam o conteúdo dela) e definir o proprietário da pasta para root:jupyterhub-instructors
que os instrutores possam controlar o conteúdo da pasta.
Se tudo mais falhar, suponho que posso criar subpastas na submissions
pasta de propriedade de cada instrutor e, em seguida, definir o sticky bit em cada subpasta. Gostaria de evitar a futura manutenção associada a isso, já que terei que ser o único a lembrar de configurar uma nova pasta no próximo semestre para cada instrutor.
Vejo várias abordagens para fazer isso; nenhuma delas é agradável e fácil.
separar pastas e inotify 1: entrada e coleta
Você cria uma
input
pasta com777
e configura o inotify para ela. Quando um usuário cria um arquivo (fecha o descritor de arquivo), um script é acionado que775
diretório660
rw
ACE para o antigo proprietário(possível) desvantagem: Os usuários podem ver os arquivos dos outros usuários (mas não o conteúdo deles).
separar pastas e inotify 2: uma por usuário, uma para o grupo
Em vez de ter apenas uma pasta para todos, você cria uma pasta (
770
) parajupyterhub-instructors
cada usuário (700
).O script inotify
${username}-${original_filename}
660
rw
ACE para o antigo proprietárioo sistema de arquivos FUSE bindfs ( https://bindfs.org/ )
Não testei isso.
bindfs
ignora o bit sticky. Não tenho certeza do que "ignora" significa neste contexto. A pasta pública teria1777
e (em algum lugar) abaixo de um750
"diretório de controle de acesso" você criaria umabindfs
montagem que forçaria todos os arquivos para?6?
. Acho que o bit sticky do diretório original não impediria alterações feitas neste caminho (mas não tenho certeza).Controle de acesso NFS4
Você monta o diretório via NFS4 (do mesmo sistema) e configura as permissões que deseja...
vantagem: apenas um diretório (possível) desvantagem: os usuários podem ver os arquivos de outros usuários ou nem mesmo os seus próprios.
Os nomes dos arquivos serão previsíveis e únicos? Se não, definir as permissões no diretório para
0773
e tê-lo como propriedade deroot:jupyterhub-instructors
permitirá que os alunos soltem arquivos no diretório, mas não listem o conteúdo do diretório. Todos os membros dejupyterhub-instructors
terão controle total do diretório.Qualquer usuário que saiba o nome de um arquivo específico poderá listá-lo e possivelmente ver o conteúdo, dependendo das permissões de arquivo que o usuário original atribuiu a ele.