cryptohome: Passthrough directory does not override existing non-passthrough directory. |
||||||||
Issue descriptionSplit out from Bug 728892 . Chrome Version: 61.0.3119.0 OS: 9623.0.0 What steps will reproduce the problem? (1) log-in to an user on ecryptfs (not ext4-crypto) filesystem (i.e., use a device on which Android N is not enabled) (2) (from terminal) # rm -rf /home/chronos/user/GCache/v1/tmp (3) Go to chrome://inducebrowsercrashforrealz (= trigger a browser process crash) (4) Log-out and log-in again. (5) (from terminal) # ls /home/chronos/user/GCache/v1 What is the expected result? At most one "tmp" directory. What happens instead? Two "tmp" directories. When mounting the home directory, the intention of cryptohome is to recursively delete "/home/chronos/user/GCache/v1/tmp" if it existed as an encrypted path, and overwrite it with a pass-through (non-encrypted filename) directory: https://chromium.googlesource.com/chromiumos/platform2/+/master/cryptohome/mount.cc#993 but the code has a bug as of now, and because of that, both the pass-through and non-pass-through 'tmp' directories are kept. As a result, * Ext4-crypto migration tool is confused ( Bug 728892 ). * Cache deletion by cryptohome is probably not working as intended (Encrypted directory seems to be preferred when the dup'ed path is operated. Hence no file is created under the pass-through path.)
,
Jun 7 2017
As far as I experimented, always the non-pass-through one was taken. Though I cannot be sure without investigating the ecryptfs impl if it is just by an accident or not. https://chromium-review.googlesource.com/#/c/526833/ is the CL for stopping to create the dup. On which I don't have a good idea yet is how to avoid the already created dups.
,
Jun 7 2017
Seems the behavior depends on the state of cache. After executing these commands: cd /home/.shadow/ mkdir mount/A; mkdir vault/A; rmdir mount/A ls vault/ You will see an encrypted directory in vault. However, after the same commands with drop_caches, you will see the passthrough one left: cd /home/.shadow/ mkdir mount/A; mkdir vault/A; echo 3 > /proc/sys/vm/drop_caches rmdir mount/A ls vault/
,
Jun 7 2017
Sorry for causing this trouble, as far as I experimented, duplicates can be resolved with the following steps (probably there is a simpler way): 1. Detect duplicates by checking if a tracked directory's name appears twice in readdir() result. 2. Rename the passthrough one to a temporary name (e.g. tmp -> tmp_) 3. echo 3 > /proc/sys/vm/drop_caches to drop cache (otherwise, the next step may delete the passthrough one) 4. Remove the non-passthrough directory. 5. Rename the passthrough one again to the original name.
,
Jun 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/51dd8de2eea1697ce6f0e4b813751000998cd147 commit 51dd8de2eea1697ce6f0e4b813751000998cd147 Author: Kazuhiro Inaba <kinaba@chromium.org> Date: Thu Jun 08 06:45:43 2017 cryptohome: Delete the right path when overriding with a passthrough dir. The relative path |tracked_dir| now starts from "root/" or "user/", hence the base directory must be one level up from the "user" directory. BUG= chromium:729997 TEST=crs_workon_make cryptohome --test TEST=Manual step shown in the bug Change-Id: If91d17c8897c4d4c8c77c86d4e46d62f429c75dd Reviewed-on: https://chromium-review.googlesource.com/526833 Commit-Ready: Kazuhiro Inaba <kinaba@chromium.org> Tested-by: Kazuhiro Inaba <kinaba@chromium.org> Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org> [modify] https://crrev.com/51dd8de2eea1697ce6f0e4b813751000998cd147/cryptohome/mount.h [modify] https://crrev.com/51dd8de2eea1697ce6f0e4b813751000998cd147/cryptohome/mount.cc [modify] https://crrev.com/51dd8de2eea1697ce6f0e4b813751000998cd147/cryptohome/mount_unittest.cc
,
Jun 8 2017
,
Jun 8 2017
,
Jun 9 2017
Your change meets the bar and is auto-approved for M60. Please go ahead and merge the CL to branch 3112 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 9 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/fd29164a5021651a3232c2812f875b0c4f62b6b9 commit fd29164a5021651a3232c2812f875b0c4f62b6b9 Author: Kazuhiro Inaba <kinaba@chromium.org> Date: Fri Jun 09 07:16:25 2017 cryptohome: Delete the right path when overriding with a passthrough dir. The relative path |tracked_dir| now starts from "root/" or "user/", hence the base directory must be one level up from the "user" directory. BUG= chromium:729997 TEST=crs_workon_make cryptohome --test TEST=Manual step shown in the bug Change-Id: If91d17c8897c4d4c8c77c86d4e46d62f429c75dd Reviewed-on: https://chromium-review.googlesource.com/526833 Commit-Ready: Kazuhiro Inaba <kinaba@chromium.org> Tested-by: Kazuhiro Inaba <kinaba@chromium.org> Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org> (cherry picked from commit 51dd8de2eea1697ce6f0e4b813751000998cd147) Reviewed-on: https://chromium-review.googlesource.com/527744 Reviewed-by: Kazuhiro Inaba <kinaba@chromium.org> Commit-Queue: Kazuhiro Inaba <kinaba@chromium.org> Trybot-Ready: Kazuhiro Inaba <kinaba@chromium.org> [modify] https://crrev.com/fd29164a5021651a3232c2812f875b0c4f62b6b9/cryptohome/mount.h [modify] https://crrev.com/fd29164a5021651a3232c2812f875b0c4f62b6b9/cryptohome/mount.cc [modify] https://crrev.com/fd29164a5021651a3232c2812f875b0c4f62b6b9/cryptohome/mount_unittest.cc
,
Jun 9 2017
,
Jun 12 2017
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 12 2017
It's already merege
,
Jan 22 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by hashimoto@chromium.org
, Jun 7 2017