← Back to team overview

desktop-packages team mailing list archive

Re: [Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss


On 2015-02-24 04:32:21, Rocko wrote:
> I think it is still useful for ecryptfs to support the btrfs clone ioctl
> for the case where both source and target higher files are in the same
> ecryptfs mount, since this saves disk space.

I don't like the idea of eCryptfs supporting the clone ioctl by default.
It would allow an attacker to discover that the files (the original and
the clone) are the same. Sure, the decrypted file size of eCryptfs files
is stored in plaintext so an attacker would already know that the two
files are the same size but that doesn't mean that they contain the same

A core design aspect of eCryptfs is that a unique File Encryption Key
(FEK) is generated for each file, meaning that two matching plaintext
files will have entirely different ciphertext.

I'd consider allowing support for the clone ioctl down the road if the
user specified an eCryptfs mount option that implies that
performance and efficiency are more important than security.

Supporting sparse files in eCryptfs could fall under that same mount

> We might be able to handle this in
> fs/ecryptfs/file.c#ecryptfs_unlocked_ioctl, which gets passed the btrfs
> ioctrl clone command along with the the higher target file. It
> unconditionally converts it to the lower file and then passes it down to
> btrfs:
>   struct file *lower_file = ecryptfs_file_to_lower(file);
>    ...
>   if (lower_file->f_op->unlocked_ioctl)
>     rc = lower_file->f_op->unlocked_ioctl(lower_file, cmd, arg);
> Adding code here that returns failure if the command is BTRFS_IOC_CLONE
> makes the cp --reflink=always command fail. (cp --reflink=auto then
> works because cp detects the failure and does a non-clone copy, and the
> same should go for the glib file copy).
> However, note that:
> 1. When it fails to clone, ecryptfs still creates a valid but zero-byte
> file after the failed clone operation, so ecryptfs should probably
> remove this when it returns fail for the clone operation.

This is a bug in the cp program, if anything. The same thing happens on
ext4. Here's what we see from strace:

$ strace cp --reflink=always test test.copy
open("test", O_RDONLY)                  = 3
fstat(3, {st_mode=S_IFREG|0664, st_size=5, ...}) = 0
open("test.copy", O_WRONLY|O_CREAT|O_EXCL, 0664) = 4
fstat(4, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
ioctl(4, BTRFS_IOC_CLONE, 0x3)          = -1 ENOTTY (Inappropriate ioctl for device)

cp opens test, then creates test.copy, before calling ioctl() on
test.copy's file descriptor. The clone fails but then cp never unlinks

> 2. It shouldn't fail if the source and target files are both inside the
> same ecryptfs mount.

I feel like it should fail for the reasons mentioned above.

If someone wants to add BTRFS clone support down the road, that'd be
nice. However, I think this bug is properly fixed by returning an error
when ecryptfs_{compat,unlocked}_ioctl() sees BTRFS_IOC_CLONE. That's the
only backportable fix.

In fact, I think eCryptfs should probably be returning error on any
filesystem specific ioctl commands. There are a handful ioctl commands
common across all filesystems that it should support and pass down to
the lower filesystem but all others are unknowns and should be

> 3. Do symlinks affect it, eg if the target is a symlink outside the
> ecryptfs mount that points to the higher ecryptfs file?

Good question. That'll be something to test if anyone ever adds clone

> 4. ecryptfs_compat_ioctl might possibly be affected as well since it
> does the same thing as ecryptfs_unlocked_ioctl.

I think you're right.

You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.

  Cutting or copying files on btrfs to ecryptfs results in data loss

Status in eCryptfs:
Status in The Linux Kernel:
Status in linux package in Ubuntu:
Status in nautilus package in Ubuntu:

Bug description:
  I've installed a fresh copy of 14.04 beta 2 on a brand-new SSD.  I
  used btrfs as the filesystem.

  I set up a Private folder usying ecryptfs-setup-private.

  I copied a few folders into the Private folder, and the entire
  directory structure and subfolders are copied, including the files
  themselves, yet every file contains 0 bytes.

  However, I can create and save new files in the Private directory.
  Also, folders and files can be correctly copied if I use the command line cp -R.


  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: nautilus 1:3.10.1-0ubuntu8
  ProcVersionSignature: Ubuntu 3.13.0-23.45-generic 3.13.8
  Uname: Linux 3.13.0-23-generic x86_64
  ApportVersion: 2.14.1-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Apr  9 18:12:56 2014
  EcryptfsInUse: Yes
  GsettingsChanges: b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size', 'type', 'date_modified', 'date_accessed', 'owner', 'group', 'permissions', 'mime_type', 'where']"
  InstallationDate: Installed on 2014-04-05 (4 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Beta amd64 (20140326)
   PATH=(custom, no user)
  SourcePackage: nautilus
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to: