What should be the mode, 555?

https://chromium-review.googlesource.com/#/c/413226/2/client/site_tests/platform_FilePerms/platform_FilePerms.py

To be clear, I want to fix this test. Looking at pfq for context.

If you look at verity_mounter.cc (https://cs.corp.google.com/chromeos_internal/src/platform/imageloader/verity_mounter.cc), it doesn't pass any mode= string to the mount() system call. Should imageloader be passing that information through?

If I recall correctly, since this is a squashfs image, you cannot pass a mode= string through the mount, because the mode is going to be fixed (it's a read only image).

Just to be clear, as component updates are enabled in 2985 the problem is not strictly with platform_ImageLoaderServer. Disabling it may reduce the flakes, but as components are still downloaded independently of the test, it won't make them disappear. So the fix needs to be in platform_FilePerms.

That is a good point. I just wanted to temporarily clear the flakes because of the timezone difference. If this can wait for me to fix platform_FilePerms and post a fix by the end of day Syndey time, I'm happy to do it.

I am in the process to do the fix.

Thinking a bit more about your change, it will do nothing as platform_FilePerms runs before platform_ImageLoaderServer. So this is strictly coming from Chrome.

I see. Thank you for handling this Ilja. I will be back online in a couple hours to provide any help as needed.

If I understand this right we should check for 555 but not read it from mtab. I am disabling the check for now from platform_FilePerms as it isn't right. This should unbreak cq/pfq etc.
https://chromium-review.googlesource.com/430203


localhost ~ # stat  /run/imageloader/PepperFlashPlayer
  File: '/run/imageloader/PepperFlashPlayer'
  Size: 76        	Blocks: 0          IO Block: 4096   directory
Device: fe02h/65026d	Inode: 3           Links: 2
Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: u:object_r:unlabeled:s0
Access: 2017-01-18 23:42:21.000000000 -0800
Modify: 2017-01-18 23:42:21.000000000 -0800
Change: 2017-01-18 23:42:21.000000000 -0800
 Birth: -

localhost ~ # grep Pepper /etc/mtab 
/dev/mapper/068D4214B37C5D935BC3CCCE590739299406945E3CD013F9C904400067FD5351 /run/imageloader/PepperFlashPlayer squashfs ro,seclabel,nosuid,nodev,relatime 0 0

achuith fyi

Is this the same failure:
https://uberchromegw.corp.google.com/i/chromeos/builders/daisy_skate-chrome-pfq/builds/3369

One of the recent PFQ breaks.

I get 502 errors trying to read the logs, but presumably the same.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/91232bf9da144a060225c27c6fbec5610cb42194

commit 91232bf9da144a060225c27c6fbec5610cb42194
Author: Ilja H. Friedel <ihf@chromium.org>
Date: Thu Jan 19 22:32:27 2017

platform_FilePerms: remove permission check from imageloader.

/run/imageloader/PepperFlashPlayer is created once Chrome downloads
a new component update from Omaha.

BUG= chromium:682811 
TEST=Ran locally on samus.

Change-Id: Iee1c03266913014a5dc1aa59679f5c7e60cacc81
Reviewed-on: https://chromium-review.googlesource.com/430203
Tested-by: Ilja H. Friedel <ihf@chromium.org>
Trybot-Ready: Ilja H. Friedel <ihf@chromium.org>
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>

[modify] https://crrev.com/91232bf9da144a060225c27c6fbec5610cb42194/client/site_tests/platform_FilePerms/platform_FilePerms.py

Just for reference: https://luci-milo.appspot.com/buildbot/chromeos/peach_pit-chrome-pfq/3016 failing the same reason

01/18 20:02:44.119 ERROR|platform_FilePerms:0330| [/etc/mtab] "/run/imageloader/PepperFlashPlayer" is missing options "set(['mode=755'])"

Hopefully fixed on the next run.

I did not realize platform_FilePerms was checking the PepperFlashPlayer mount. This raises a good point: we are going to add support to mount arbitrary components, so hardcoding the mount points won't scale over time.

I think the "right" fix for the long term is for me to have that test enforce a certain set of rules against any mount point under /run/imageloader. What do you think?

Thanks again for fixing this.

No more failures.