** Changed in: ecryptfs
Status: Opinion => Fix Released
** Changed in: linux (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
** Changed in: ecryptfs
Status: Confirmed => Opinion
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ecryptfs results in data
It has been fixed for me since kernel 4.0, so yes, I think it can be
closed now.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to
Can this ticket be closed?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ecryptfs results in data loss
Status in eCryptfs:
Linux pratomo-X450JB 4.5.0-040500rc7-generic #201603061830 SMP Sun Mar 6
23:33:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Seems to be working now on my arch machine.. Great work!!!
It noticed something though:
When I move a (large) file to ecryptfs folder this now seems to happen
instantly. As I remember it (on ext4 machines) moving files would take a while
and show a progress bar, like you see when moving to
Cool, I see the patch is in 4.0-rc3 now (commit
6d65261a09adaa374c05de807f73a144d783669e).
I applied it to 3.19.1-generic and can confirm it works as advertised.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
** No longer affects: nautilus (Ubuntu)
** Tags added: kernel-fs
** Changed in: linux (Ubuntu)
Status: Confirmed = Triaged
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
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
** Tags removed: kernel-key
** Tags added: kernel-da-key
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ecryptfs results in data loss
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.
I agree with that reasoning.
In any case, I think that the btrfs clone operation should be disallowed
in ecryptfs as a
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)
In case anyone still reads bugzilla.kernel.org, I reported this at
https://bugzilla.kernel.org/show_bug.cgi?id=93691.
** Bug watch added: Linux Kernel Bug Tracker #93691
http://bugzilla.kernel.org/show_bug.cgi?id=93691
--
You received this bug notification because you are a member of Kernel
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.
We might be able to handle this in
fs/ecryptfs/file.c#ecryptfs_unlocked_ioctl, which gets passed the btrfs
Thanks for the in-depth triage of this bug, Rocko. As you pointed out, I
can easily reproduce this using cp's --reflink=always option.
I'm marking nautilus as Invalid since this is definitely an eCryptfs
bug. I'll start determining the best way to fix this issue.
** Changed in: nautilus (Ubuntu)
The `cp --reflink=always test test.bak` is always issuing the
BTRFS_IOC_CLONE ioctl, even on non-btrfs filesystems. eCryptfs passes
ioctls down to the lower filesystem but I suspect that it should stop
doing that altogether or possibly only allow a white list of known good
ioctls.
--
You
ecryptfs_unlocked_ioctl gets passed the (higher) target file struct as
the first argument, the command as the second, and the source file
descriptor as the third argument. It looks like the source file
descriptor has already been converted to the lower file if it is
associated with a higher file
** Changed in: linux (Ubuntu)
Assignee: (unassigned) = Tyler Hicks (tyhicks)
** Changed in: ecryptfs
Assignee: (unassigned) = Tyler Hicks (tyhicks)
** Changed in: ecryptfs
Importance: Undecided = Critical
--
You received this bug notification because you are a member of Kernel
I checked the mainline 3.11 kernel and it has the bug (as well as 3.13,
3.18 and 3.19, based on the other comments), so I would say it is not a
regression.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
@whoop: If you mean that the thumbnail file length is correct but the
image file is zero bytes, the reason is that the thumbnail file isn't
copied from the non-ecryptfs folder to the ecryptfs folder. Instead, the
system stores thumbnails in ~/.cache/thumbnails. So it creates a new
thumbnail file
@Rocko: Do you have an explanation on why the thumbnail gets broken when
I cp a jpg to the ecryptfs folder? The number of bytes are correct...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
I still have a running system with this issue.
It is not an ubuntu box but Arch 64. This is a fresh install.
I stole the disk layout from the ubuntu documentation for this system:
one btrfs partition with @ subvolume for / and @home subvolume for /home.
The system also uses a vfat ESP as it is
Just to note: in the example commands above, of course, /home needs to
be write-accessible to the current user, or you need to use a command
like su root -c echo test /home/test.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
The 3.19 kernel still has the problem.
You can reproduce it by copying a test file from say /home into an
encrypted home directory using --reflink:
echo test /home/test
cp --reflink=always /home/test ~
ls -l ~/test # This shows 0 bytes
This command, however, copies the file correctly,
** Tags added: kernel-bug-exists-upstream
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ecryptfs results in data loss
Status in
Did this issue start happening after an update/upgrade? Was there a
prior kernel version where you were not having this particular problem?
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v3.19
Hi Joseph,
This bug freaked me out so much I re-formatted to EXT4 and started over.
I don't have a system that I can test this on now.
The bug appeared on a completely fresh install of 14.04 beta 2 and the
bug was still present in the release.
Unfortunately, I never had any experience with
Also, just to confirm, this issue only happens if you copy the files
using Nautilus? It does not happen if you copy from a terminal?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
** Package changed: linux-meta (Ubuntu) = linux (Ubuntu)
** Changed in: linux (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
** Also affects: linux-meta (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to
31 matches
Mail list logo
