Estou tentando usar uma pasta compartilhada do Dropbox para tornar os arquivos HTML facilmente editáveis por várias pessoas e estou (re) montando a pasta do Dropbox em algum lugar /var/www/com a --bindopção Eu tenho o contexto SELinux definido para a pasta Dropbox para que os itens contenham um httpd_sys_content_ttipo que httpd(no RHEL6) possa ler. Isso tudo funciona e os arquivos estão disponíveis no site. A edição de um arquivo na pasta Dropbox no servidor da web também funciona (o contexto do SELinux é mantido).
No entanto, quando o arquivo é atualizado via Dropbox (digamos, alguém o edita), o arquivo resultante no final do recebimento (após a atualização do Dropbox) sempre recebe um contexto user_home_te, portanto, o Apache não pode ler o arquivo e, portanto, resulta em 403 Proibido erro (até eu restaurar manualmente o contexto).
Tentei configurar o contexto para ~/.dropbox/a httpd_sys_content_t, que também funciona: (?) O cache arquivos em ~/.dropbox/l/obter esse contexto, mas, em seguida, o arquivo atualizado no ~/Dropbox/ainda recebe user_home_t. Isso indica que o Dropbox atualiza o arquivo em outro lugar (presumivelmente por meio do método delta) e, em seguida, faz o equivalente mva movê-lo para a pasta Dropbox (uma vez que no SELinux mvpreserva o contexto da origem e o cpredefine de acordo com o destino).
Notas:
- Não desejo desabilitar o SELinux (mas isso resolve o problema)
- Com relação ao uso de
httpd_sys_content_t: eu poderia eventualmente criar uma política especial para lidar com esses arquivos que podem ser mais sensatos do que apenas usar,httpd_sys_content_tmas vou me preocupar com isso mais tarde - Eu poderia executar um pequeno script que fazia uma
restorecon -Rna subpasta do Dropbox apropriada a cada 5 ou 10 segundos, mas preferia capturá-lo mais cedo
Então: onde o Dropbox cria o arquivo recém-atualizado antes de voltar para a pasta do Dropbox? Quaisquer outros pensamentos sobre outra coisa para tentar?
Obrigado!
David
~/.dropbox/!