yamaguchi@ - Could you please take a look?

I confirmed this happens on latest.

Not directly related, but double-click is not processed right in the latest ( Issue 826134 ). So we need to test this with right-click and open.

I found that ZIP file is accessed correctly although it's also based on avfs. (I tested it by putting #disable-new-zip-unpacker and #disable-zip-archiver-unpacker flags.)
However, if we do like this, it shows the file content correctly.
# mountavfs
# cd .avfs/foo/bar.rar#/
# cat file.txt
So I don't think this is problems inside avfs/fuse itself.

I found this happens on some rar but not others.
I've attached files that fails and passes.

localhost /media/archive # ls a?.rar/a.txt -l                                  
-rw-r--r--. 1 chronos chronos 15 Nov  7 20:33 a1.rar/a.txt
-rw-r--r--. 1 chronos chronos 15 Nov  7 20:33 a2.rar/a.txt
localhost /media/archive # file a?.rar/a.txt                                   
a1.rar/a.txt: regular file, no read permission
a2.rar/a.txt: ASCII text

Deleted: a1.rar 92 bytes

a1.rar 92 bytes Download

Deleted: a2.rar 79 bytes

a2.rar 79 bytes Download

benchan@, did we change permissions around avfs or cros-disks after M65 branch?
So far I see this since M66 branch and later, but not in M65.

Seems /usr/bin/unrar is crashing when reading content (not just filename, but contents) of a certain pattern of archive due to SISSYS / bad system call. uid 301 is avfs.

* * *

<< from /var/log/messages >>

2018-04-04T12:13:22.032786+09:00 NOTICE kernel: [ 7347.404275] audit: type=1326 audit(1522811602.030:296): auid=4294967295 uid=301 gid=1001 ses=4294967295 subj=u:r:chromeos:s0 pid=18620 comm="unrar" exe="/usr/bin/unrar" sig=31 arch=c000003e syscall=218 compat=0 ip=0x7fb5ef5bcae7 code=0x0
2018-04-04T12:13:22.040275+09:00 INFO crash_reporter[18621]: libminijail[18621]: mount /dev/log -> /dev/log type ''
2018-04-04T12:13:22.041744+09:00 DEBUG kernel: [ 7347.413399] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
2018-04-04T12:13:22.051879+09:00 DEBUG kernel: [ 7347.423106] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
2018-04-04T12:13:22.062270+09:00 WARNING crash_reporter[18621]: [user] Received crash notification for unrar[18620] sig 31, user 301 (developer build - not testing - always dumping)
2018-04-04T12:13:22.064483+09:00 INFO crash_reporter[18621]: State of crashed process [18620]: S (sleeping)
2018-04-04T12:13:22.075799+09:00 INFO crash_reporter[18621]: Stored minidump to /var/spool/crash/unrar.20180404.121322.18620.dmp
2018-04-04T12:13:22.076209+09:00 INFO crash_reporter[18621]: Leaving core file at /var/spool/crash/unrar.20180404.121322.18620.core due to developer image
2018-04-04T12:13:22.076949+09:00 WARNING crash_reporter[18621]: [ARC] Received crash notification for unrar[18620] sig 31, user 301 (ignoring - crash origin is not ARC)


<< when running gdb with the core files >>

Core was generated by `unrar p -c- -ierr /home/chronos/u-<<user id hash>>/GCac'.
Program terminated with signal SIGSYS, Bad system call.
* * *

Re #6:  There is no cros-disks/AVFS related change from release-R65-10323.B to release-R66-10452.B. The platform_CrosDisksArchive.rar test is passing in M66 and ToT.  So I suspect the issue may be related to some RAR file, which triggers a syscall that isn't whitelisted.

Do you have the RAR file that reproduce the issue?

The first one in #5 reproduces the issue.
https://bugs.chromium.org/p/chromium/issues/attachment?aid=332574&signed_aid=uqPSQtek2a_npG5SrArw0g==

Seems like getrlimit and set_tid_address syscall were issued (and blocked by the seccomp filter) when I tried to read a1.rar:a.txt with a ToT image. Here's a potential fix: https://chromium-review.googlesource.com/c/chromiumos/platform2/+/994342 (will update the CL to include the policy for arm as well)

I haven't checked if a1.rar can be read with older Chrome OS releases, so I can't confirm if the issue is triggered by some RAR files or due to some change outside cros-disks/avfs around M65/M66 (e.g. I remember FUSE was upgraded around that time frame). 

Whitelisting getrlimit should be fine, but need to check if whitelisting set_tid_address raises any concern.

I think this can happen with more general RAR files.

I confirmed that 64.0.3282.190 and 65.0.3325.39 could read the file.
With ToT, I also confirmed it happens on other RAR files which I made with RAR 5.40.

Although the issue was not triggered with some small RAR files.
My guess was that it needed to have a significant amount of file content and actual compression happening to trigger the issue. (a1.rar and a2.rar contains exactly the same file, but a2.rar looks uncompressed; it looks containing uncompressed data content in the dump. I made a1.rar long ago, so probably with a different version of RAR.)

I'd say set_tid_address is likely fine, you probably need that to implement threading stuff (like futexes).

Thanks. Assigning this issue to benchan@ per the potential fix in #9.
We would like to fix this on M66 as this is a regression, but let us know if the fix is not simple enough.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/adf4844e956e653e0ec2b0e7baeb0faf0727d2e7

commit adf4844e956e653e0ec2b0e7baeb0faf0727d2e7
Author: Ben Chan <benchan@chromium.org>
Date: Fri Apr 06 05:12:53 2018

cros-disks: whitelist 'getrlimit' and 'set_tid_address' for AVFS

It's observed that the 'getrlimit' and 'set_tid_address' syscall are
sometimes used by the AVFS process (see chromium:825934) and thus need
to be whitelisted in the seccomp BPF filter policy.

BUG= chromium:825934 
TEST=Run platform_CrosDisksArchive tests on various processor architectures.
TEST=Test opening the RAR files attached in chromium:825934#c5 in Files.app.

Change-Id: Ic6767a60f42204d1ced6734dfd703e2c8bb0ce5b
Reviewed-on: https://chromium-review.googlesource.com/994342
Commit-Ready: Ben Chan <benchan@chromium.org>
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>

[modify] https://crrev.com/adf4844e956e653e0ec2b0e7baeb0faf0727d2e7/cros-disks/avfsd-seccomp-amd64.policy
[modify] https://crrev.com/adf4844e956e653e0ec2b0e7baeb0faf0727d2e7/cros-disks/avfsd-seccomp-x86.policy
[modify] https://crrev.com/adf4844e956e653e0ec2b0e7baeb0faf0727d2e7/cros-disks/avfsd-seccomp-arm.policy

This bug requires manual review: We are only 10 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/4f78ae1dfe2a9ae51978b11e3f5723d47cb6268b

commit 4f78ae1dfe2a9ae51978b11e3f5723d47cb6268b
Author: Ben Chan <benchan@chromium.org>
Date: Tue Apr 10 05:03:56 2018

cros-disks: whitelist 'getrlimit' and 'set_tid_address' for AVFS

It's observed that the 'getrlimit' and 'set_tid_address' syscall are
sometimes used by the AVFS process (see chromium:825934) and thus need
to be whitelisted in the seccomp BPF filter policy.

BUG= chromium:825934 
TEST=Run platform_CrosDisksArchive tests on various processor architectures.
TEST=Test opening the RAR files attached in chromium:825934#c5 in Files.app.

Change-Id: Ic6767a60f42204d1ced6734dfd703e2c8bb0ce5b
Reviewed-on: https://chromium-review.googlesource.com/994342
Commit-Ready: Ben Chan <benchan@chromium.org>
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
(cherry picked from commit adf4844e956e653e0ec2b0e7baeb0faf0727d2e7)
Reviewed-on: https://chromium-review.googlesource.com/1004354
Reviewed-by: Ben Chan <benchan@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>

[modify] https://crrev.com/4f78ae1dfe2a9ae51978b11e3f5723d47cb6268b/cros-disks/avfsd-seccomp-amd64.policy
[modify] https://crrev.com/4f78ae1dfe2a9ae51978b11e3f5723d47cb6268b/cros-disks/avfsd-seccomp-x86.policy
[modify] https://crrev.com/4f78ae1dfe2a9ae51978b11e3f5723d47cb6268b/cros-disks/avfsd-seccomp-arm.policy

Verified on ChromeOS 10452.96.0, 66.0.3359.181 stable-channel