Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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 ~/.dropbox/ to 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).

Notes:

  1. I don't wish to disable SELinux (but doing so does fix the problem)
  2. 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_t but I'll worry about that later
  3. I could run a little script that did a restorecon -R on 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?

Thanks!

David

share|improve this question
add comment

1 Answer 1

up vote 1 down vote accepted

The temporary file is created in ~/Dropbox/.dropbox.cache/, then moved to its real location, to ensure atomic updates.

Workaround #3 should work – you can use incron, it would execute the command as soon as a file is changed.

share|improve this answer
    
Thanks, v. silly of me not to find the right cache location, but I was fixed on looking in ~/.dropbox/! –  manyon May 15 '12 at 4:32
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.