Comportamento de gravação diferente para o proprietário e membro do grupo, apesar de 775 permissões

3

Eu montei um compartilhamento remoto através do meu fstab usando a linha:

//path/to/target /media/f cifs gid=<mygroup's id>,dir_mode=0775,file_mode=0775 0 0

Como resultado, tudo em /media/f acaba com permissões semelhantes a esta:

$ ls -al
drwxrwxr-x 0 root mygroup ...

Eu fiz o usuário www-data um membro de mygroup , com o objetivo de permitir que um webapp do Django para gravar arquivos dentro de /media/f . No entanto, isso não funciona. Eu recebo erros de permissão.

Em um esforço para corrigir o problema, alterei a linha de montagem para definir ambos o gid e uid para que o ponto de montagem tenha usuário www-data e grupo mygroup . Então agora meu ponto de montagem é assim:

$ ls -al
drwxrwxr-x 0 www-data mygroup ...

E tudo funciona bem.

A pergunta: por que meu webapp pode gravar em /media/f quando a pasta pertence a www-data:mygroup , mas não quando pertence a root:mygroup (sabendo que www-data é um membro de mygroup ?

Eu tentei remontar, bem como reiniciar, na esperança de obter a associação de www-data (o usuário) para o grupo mygroup para "ficar", mas isso simplesmente não funciona.

Curiosamente, quando configurado com a propriedade root:mygroup , se eu sudo su www-data e, em seguida, tentar gravar em /media/f do terminal, tudo funciona bem. Alguma ideia do que está acontecendo lá? É como se o processo uwsgi que está executando o django não estivesse sendo executado com as permissões totais que eu tentei conceder a www-data .

Pensamentos?

    
por 8one6 04.12.2014 / 17:37

1 resposta

2

Acontece que isso foi bastante específico para o contexto descrito acima. Eu estava usando o uWSGI para servir meu site usando o modo imperador. Eu defino os parâmetros uid=www-data e gid=www-data . Eu esperava que isso fizesse com que meus processos vassalos tivessem as permissões associadas ao usuário e o grupo www-data , bem como as permissões associadas a qualquer grupo ao qual www-data (o usuário) pertence. Esta suposição é incorreta . Os vassalos não são executados (por padrão) com nenhum IDs de grupo suplementares.

Acontece que o uWSGI (em versões recentes) tem uma correção para isso. Você pode especificar manualmente add-gid=mygroup na configuração do uWSGI. Você pode especificar esse parâmetro várias vezes para adicionar o número de gids a um processo vassalo que seu coração desejar. Este recurso está disponível apenas a partir do uWSGI 1.9.15, portanto, você pode precisar atualizar para usar essa abordagem.

Anotações completas aqui .

Espero que isso ajude alguém!

    
por 08.12.2014 / 15:56