As a follow-up to comment #16: generally attempting to clone a file in
a non-ecryptfs folder into a mounted ecryptfs folder appears to succeed
but in fact creates a zero-length invalid target file, but going the
other way (cloning from the mounted ecryptfs folder into the non-
ecryptfs folder) fails as it should. (Both cp --reflink=auto and glib's
file_copy_fallback try a clone operation and then try a non-clone
operation if this fails, so this second case is fine.)
The attached script demonstrates both cases by creating a mounted
ecryptfs system in /tmp/ecryptfs-test and using the folder 'private' to
hold the 'lower' encrypted ecryptfs files and the folder 'plaintext' as
the 'higher' mounted ecryptfs folder and then trying the clone operation
in both directions. ( /tmp must be on a btrfs partition and you need at
least ecryptfs-utils installed but you don't need an encrypted home
folder.)
The btrfs_ioctl_clone command (in fs/btrfs/ioctl.c in the kernel source)
is designed to only perform a clone if the source and dest files have
the same VFS mountpoint and to fail with EXDEV (invalid cross-device
link) if they don't:
ret = -EXDEV;
if (src_file.file->f_path.mnt != file->f_path.mnt)
goto out_fput;
When trying to clone from the 'plaintext' folder into /tmp/ecryptfs-
test, this test fails (the mountpoints are represented by two different
dentries, '@' and '/').
However, when cloning into the 'plaintext' folder, btrfs_ioctl_clone is
actually being asked to clone using the 'lower' ecryptfs file as the
target (ie the target points to the 'private' folder, not the
'plaintext' folder), so the test passes. This is obviously wrong -
ecryptfs is designed so that the information gets directed to the
'plaintext' folder, intercepted in the kernel, and stored encrypted
instead in the 'private' folder.
To demonstrate this, I added this code just before the test:
{
#define BUFLEN 256
char src_path[BUFLEN],dest_path[BUFLEN];
int i;
for (i=0;i<BUFLEN;++i) src_path[i]=dest_path[i]=0;
printk(KERN_INFO "btrfs reflink src: %s [mnt %s], dest: %s [mnt %s]\n",
dentry_path_raw(src_file.file->f_path.dentry, src_path, BUFLEN),
src_file.file->f_path.mnt->mnt_root->d_iname,
dentry_path_raw(file->f_path.dentry, dest_path, BUFLEN),
file->f_path.mnt->mnt_root->d_iname
);
}
With that code included in the kernel, the syslog shows something like
this after running the attached test script:
... btrfs reflink src: /@/tmp/ecryptfs-test/test [mnt @], dest: /@/tmp
/ecryptfs-test/private/ECRYPTFS_FNEK_ENCRYPTED... [mnt @]
ie the target file passed to btrfs_ioctl_clone is the 'lower' file in
'private'. (Note that after the clone, trying to access this file
results in an I/O error.)
I checked the cp code, and it calls:
return ioctl (dest_fd, BTRFS_IOC_CLONE, src_fd);
I used readlink to get the file path for dest_fd from
/proc/self/fd/<file desriptor>, and it returned "/tmp/ecryptfs-
test/plaintext/test", so desc_fd in the cp command is pointing to the
correct path for the 'higher' file.
My guess is that ecryptfs intercepts this 'higher' path and converts it
to the 'lower' path before it gets passed through to btrfs, but it
should just do a pass-through for the btrfs clone operation.
** Attachment added: "Script demonstrating the bug"
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1305335/+attachment/4325528/+files/test-reflink.sh
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ecryptfs results in data loss
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
