New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 729997 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Closed: Jun 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug

Blocking:
issue 728892



Sign in to add a comment

cryptohome: Passthrough directory does not override existing non-passthrough directory.

Project Member Reported by kinaba@chromium.org, Jun 6 2017

Issue description

Split 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.)
 
When you run ls /home/chronos/user/GCache/v1/tmp/, which tmp is preferred?
It behaves randomly?
If we can know if a directory is a pass-through one or not, we can fix Mount::CreateTrackedSubdirectories to stop creating dupes.
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.
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/
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.
Project Member

Comment 5 by bugdroid1@chromium.org, 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

Labels: Merge-Request-60

Comment 7 by uekawa@google.com, Jun 8 2017

Cc: oka@chromium.org
Project Member

Comment 8 by sheriffbot@chromium.org, Jun 9 2017

Labels: -Merge-Request-60 Hotlist-Merge-Approved Merge-Approved-60
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
Project Member

Comment 9 by bugdroid1@chromium.org, Jun 9 2017

Labels: merge-merged-release-R60-9592.B
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

Status: Fixed (was: Started)
Project Member

Comment 11 by sheriffbot@chromium.org, 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
Labels: -Hotlist-Merge-Approved -Merge-Approved-60 Merge-Merged
It's already merege

Comment 13 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment