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

Issue 776841 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

login_Cryptohome failed: "user\040(deleted)" not expected

Project Member Reported by gwendal@chromium.org, Oct 20 2017

Issue description

Looking at failure in https://luci-milo.appspot.com/buildbot/chromeos/veyron_mighty-paladin/6967

In the debug log:
https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/150320521-chromeos-test/chromeos4-row6-rack11-host8/login_Cryptohome/debug/login_Cryptohome.DEBUG [enclosed]

The user id is 734295213a3d83f97a347b4b7272ebd010131aa3

His directory is mounted:
..
/dev/mmcblk0p1 /home/chronos/user\040(deleted) ext4 rw,seclabel,nosuid,nodev,noexec,relatime,commit=600,data=ordered 0 0
/dev/mmcblk0p1 /home/user/734295213a3d83f97a347b4b7272ebd010131aa3\040(deleted) ext4 rw,seclabel,nosuid,nodev,noexec,relatime,commit=600,data=ordered 0 0
/dev/mmcblk0p1 /home/chronos/u-734295213a3d83f97a347b4b7272ebd010131aa3 ext4 rw,seclabel,nosuid,nodev,noexec,relatime,commit=600,data=ordered 0 0
...

10/19 20:45:47.902 DEBUG|             utils:0212| Running 'grep /home/root/734295213a3d83f97a347b4b7272ebd010131aa3 /proc/$(pgrep cryptohomed)/mounts'
10/19 20:45:47.903 DEBUG|      global_hooks:0056| 'grep /home/root/734295213a3d83f97a347b4b7272ebd010131aa3 /proc/$(pgrep cryptohomed)/mounts'
10/19 20:45:47.936 DEBUG|             utils:0212| Running 'e4crypt  get_policy /home/user/734295213a3d83f97a347b4b7272ebd010131aa3\040(deleted) | cut -d ' ' -f 2 2>&1'
10/19 20:45:47.937 DEBUG|      global_hooks:0056| "e4crypt  get_policy /home/user/734295213a3d83f97a347b4b7272ebd010131aa3\\040(deleted) | cut -d ' ' -f 2 2>&1"
10/19 20:45:47.946 DEBUG|             utils:0280| [stderr] /bin/bash: -c: line 0: syntax error near unexpected token `('
10/19 20:45:47.948 DEBUG|             utils:0280| [stderr] /bin/bash: -c: line 0: `e4crypt  get_policy /home/user/734295213a3d83f97a347b4b7272ebd010131aa3\040(deleted) | cut -d ' ' -f 2 2>&1'
10/19 20:45:47.949 DEBUG|             utils:0212| Running 'keyctl show @s | grep  | wc -l 2>&1'
10/19 20:45:47.950 DEBUG|      global_hooks:0056| 'keyctl show @s | grep  | wc -l 2>&1'
10/19 20:45:47.965 DEBUG|             utils:0280| [stderr] Usage: grep [OPTION]... PATTERN [FILE]...
10/19 20:45:47.965 DEBUG|             utils:0280| [stderr] Try 'grep --help' for more information.
10/19 20:45:47.973 DEBUG|             utils:0280| [stdout] 0

The mount point '/home/chronos/user\040(deleted)' is not expected, it should be "/home/chronos/user". 


 
150320521-chromeos-test%2Fchromeos4-row6-rack11-host8%2Flogin_Cryptohome%2Fdebug%2Flogin_Cryptohome.txt
5.5 KB View Download
Cc: sonnyrao@chromium.org sarthakkukreti@chromium.org
Status: Available (was: Untriaged)
"\040(deleted)" indicates the mount is stale, the suffix is added in the kernel in fs/dcache.c.

/home/chronos/user normally points to /home/.shadow/734295213a3d83f97a347b4b7272ebd010131aa3/mount/user

It could be explained if /home/.shadow/734295213a3d83f97a347b4b7272ebd010131aa3/mount appears unexpectedly encrypted, /user would not be present anymore.
is this a new failure?  Could it have been caused by backports?
>> 10/19 20:45:47.949 DEBUG|             utils:0212| Running 'keyctl show @s | grep  | wc -l 2>&1'
>> 10/19 20:45:47.950 DEBUG|      global_hooks:0056| 'keyctl show @s | grep  | wc -l 2>&1'
>> 10/19 20:45:47.965 DEBUG|             utils:0280| [stderr] Usage: grep [OPTION]... PATTERN [FILE]...
>> 10/19 20:45:47.965 DEBUG|             utils:0280| [stderr] Try 'grep --help' for more information.
>> 10/19 20:45:47.973 DEBUG|             utils:0280| [stdout] 0

It seems like even the logon key is missing from the keyring.

Comment 4 by gwendal@google.com, Oct 20 2017

#3: no the problem is there no argument for grep, because "e4crypt  get_policy ..." failed.

#2: let's monitor that. Note that there was very recent backport from my side that are not in the tree yet.
Running locally with cl/724107 and friends, I notice that mounts are marked deleted in proc/../mounts:

mount | grep 98e9d5f171f58f592c08eaf7be08d8c898d39f64 | head -1
/dev/sda1 on /home/user/98e9d5f171f58f592c08eaf7be08d8c898d39f64 type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,commit=600,data=ordered)

cat /proc/$$/mounts | grep 98e9d5f171f58f592c08eaf7be08d8c898d39f64 | head -1
/dev/sda1 /home/user/98e9d5f171f58f592c08eaf7be08d8c898d39f64\040(deleted) ext4 rw,seclabel,nosuid,nodev,noexec,relatime,commit=600,data=ordered 0 0

Even when the mount point is valid:
ls -l /home/.shadow/98e9d5f171f58f592c08eaf7be08d8c898d39f64/mount/
total 16
drwxrwx--T. 3 root    daemon-store   4096 Oct 20 15:53 root
drwx--x---. 8 chronos chronos-access 4096 Oct 20 15:53 user

It does not happen on ToT. 

Status: WontFix (was: Available)
CL/724102 is the problem cause.
It has raised a lot of issues:
https://github.com/zfsonlinux/zfs/issues/3030 [autosnapshot broken]
http://www.serverphorums.com/read.php?12,763874,page=5 [DoS unprivilege mount]
https://patchwork.kernel.org/patch/9825777/ [ NFS: only invalidate dentrys that are clearly invalid],

I will not merge it in.

Sign in to add a comment