desktop-packages team mailing list archive

[Tyler Hicks <tyhicks@xxxxxxxxxxxxx>]

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
contents.

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
option.

> 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
it.

> 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
blacklisted.

> 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
support.

> 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.
https://bugs.launchpad.net/bugs/1305335

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

Status in eCryptfs:
  Confirmed
Status in The Linux Kernel:
  Unknown
Status in linux package in Ubuntu:
  Confirmed
Status in nautilus package in Ubuntu:
  Invalid

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.

  Thanks,
  Damon

  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)
  ProcEnviron:
   LANGUAGE=en_CA:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_CA.UTF-8
   SHELL=/bin/bash
  SourcePackage: nautilus
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions