I am trying to use a shared Dropbox folder to make HTML files easily editable by several people, and am (re)mounting the Dropbox folder to somewhere in
/var/www/ with the
--bind option. I have the SELinux context set for the Dropbox folder so that items inside get a
httpd_sys_content_t type, which
httpd (on RHEL6) can read. This all works and the files are available on the website. Editing a file in the Dropbox folder on the web server also works (the SELinux context is retained).
However, when the file is updated via Dropbox (say, someone else edits the file), the resulting file on the receiving end (after Dropbox has updated it) always gets a context of
user_home_t, and so Apache can't read the file and so a 403 Forbidden error results (until I go and manually restore the context).
I tried setting the context for
httpd_sys_content_t, which also works: the cache (?) files in
~/.dropbox/l/ get that context, but then the updated file in
~/Dropbox/ still gets
user_home_t. This indicates that Dropbox updates the file somewhere else (presumably via its delta method) and then does an equivalent of
mv to move it into the Dropbox folder (since under SELinux
mv preserves the context of the origin and
cp resets it according to the destination).
- I don't wish to disable SELinux (but doing so does fix the problem)
- Regarding the use of
httpd_sys_content_t: I might eventually create a special policy to deal with these files which might be more sensible than just using
httpd_sys_content_tbut I'll worry about that later
- I could run a little script that did a
restorecon -Ron the appropriate Dropbox subfolder every 5 or 10 seconds, but would rather catch this earlier
So: where does Dropbox create the newly updated file before moving it back to the Dropbox folder? Any other thoughts on something else to try?