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 em /var/www/ com a opção --bind . Eu tenho o conjunto de contexto do SELinux para a pasta Dropbox para que os itens dentro recebam um tipo httpd_sys_content_t , que httpd (no RHEL6) possa ler. Tudo isso 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, outra pessoa edita o arquivo), o arquivo resultante na extremidade de recebimento (depois que o Dropbox o atualizou) sempre obtém um contexto de user_home_t e, portanto, o Apache leia o arquivo e, assim, os resultados de um erro 403 Proibido (até que eu vá e restaure manualmente o contexto).
Eu tentei definir o contexto para ~/.dropbox/ to httpd_sys_content_t , que também funciona: os arquivos de cache (?) em ~/.dropbox/l/ obtêm esse contexto, mas o arquivo atualizado em ~/Dropbox/ ainda obtém user_home_t . Isto indica que o Dropbox atualiza o arquivo em algum outro lugar (presumivelmente via seu método delta) e então faz um equivalente a mv para movê-lo para a pasta Dropbox (já que no SELinux mv preserva o contexto da origem e cp redefine de acordo com o destino).
Notas:
httpd_sys_content_t : eventualmente, posso criar uma política especial para lidar com esses arquivos, o que pode ser mais sensato do que usar apenas httpd_sys_content_t , mas vou me preocupar com isso mais tarde restorecon -R na subpasta apropriada do Dropbox a cada 5 ou 10 segundos, mas preferiria ver isso antes Então: onde o Dropbox cria o arquivo recém-atualizado antes de movê-lo de volta para a pasta do Dropbox? Alguma outra opinião sobre outra coisa para tentar?
Obrigado!
David