Decrypted directory doesn't follow crypted when crypted is updated

[Stanislav German-Evtushenko]

I've tried to share encrypted folder using Dropbox.
If I update file on one machine it doesn't become updated on another one until I do ecryptfs-umount-private and then ecryptfs-mount-private on it.

[Stanislav German-Evtushenko (giner)]

Example:

$ ls ~/.crypt
file1
file2

$ ls ~/crypt
file1
file2

$ cat ~/crypt/file1
text1
$ cat ~/crypt/file2
text2

$ cp ~/.crypt/file1 ~/.crypt/file2
$ cat ~/crypt/file2
text2

but should be text1

[Dustin Kirkland  (kirkland)]

Howdy, thanks for this report.

I don't know much about dropbox...do you have any idea what triggers a "sync" in Dropbox? Is it based on inotify or does it have its own daemon for watching files?

Have you tried just running the command "sync" by hand instead of running the umount and then remounting it?

[Sergio Peña (sergio-pena)]

Hey,

It seems a cache related issue. this command has helped me to clean the cache and see the data updated.
# sync ; echo 3 > /proc/sys/vm/drop_caches

This bug could be reproduced on ubuntu 11.10 kernel 3.0.0-14-generic. Just read both files on ecryptfs directory
so data is cached, then copy a file from lower directory.

It would be good if eCryptfs could detect lower file data changes and update the cache to see the file updated.

[Tyler Hicks (tyhicks)]

On 2011-12-18 21:06:31, Sergio Peña wrote:
> It seems a cache related issue. this command has helped me to clean the cache and see the data updated.
> # sync ; echo 3 > /proc/sys/vm/drop_caches

This should be used carefully. Take this example of a file being
modified across two dropbox-synced machines:

1) On machine 1, the user modifies bytes 1024-2048 inside the eCryptfs
   mount point

2) The file's dirty pages go under writeback, but due to the eCryptfs
   encryption scheme (CBC over 4k extents), machine 1's lower, encrypted
   file gets modified from byte 1024 to byte 4096

3) On machine 2, the user has updated bytes 1-256 inside the
   eCryptfs mount point

4) Dropbox copies the updated file from machine 1 to machine 2

5) `sync ; echo 3 > /proc/sys/vm/drop_caches` is ran on machine 2

6) During the write out triggered by the sync, machines 2's lower,
   encrypted file gets modified from bytes 0 through 4096, losing the
   update from machine 1.

I'm not sure how dropbox would handle things at this point.

> It would be good if eCryptfs could detect lower file data changes and
> update the cache to see the file updated.

Even if we could detect them, how would we mediate them against dirty
eCryptfs pages? How do we know what is the most up-to-date data?

Unfortunately, direct modifications to the lower filesystem are simply
not supported. If a modification doesn't go through the eCryptfs mount
point, we cannot be expected to know about it due to the eCryptfs
architecture.

 status wontfix

[Stanislav German-Evtushenko (giner)]

I've been using encfs in the same way for about one year and it's been going well. Does it work in a different way?

[Tyler Hicks (tyhicks)]

On 2011-12-19 16:22:58, Stanislav German-Evtushenko wrote:
> I've been using encfs in the same way for about one year and it's been
> going well. Does it work in a different way?

I don't know enough about FUSE or encfs to answer that. Maybe encfs
doesn't cache the decrypted pages? Are you interested in researching
this a bit, Stanislav?

I've thought about adding a mount option to always bypass the eCryptfs
page cache, but I haven't heard/thought of enough usecases to make me
want to add yet another mount option for it (which adds to the testing
burden).

[Stanislav German-Evtushenko (giner)]

I'm not sure how to check but probably you right and fuse doesn't use cache (-o kernel_cache?) by default.

[Mikko Rantalainen (mira)]

> Unfortunately, direct modifications to the lower filesystem are simply
> not supported. If a modification doesn't go through the eCryptfs mount
> point, we cannot be expected to know about it due to the eCryptfs
> architecture.

Would it be possible for eCryptfs to use e.g. inotify or some other kernel signaling for cached files and to drop/reload the cache for those files that have been modified in the lower filesystem (outside eCryptfs)?

Of course, that cannot prevent losing data in user process race conditions but there's no way to fix that on filesystem level (user mode apps should use proper locking instead).