UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Steps to reproduce the problem:
1. Login as a normal user

> id
uid=1001(boriss) gid=1001(boriss) groups=1001(boriss) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

2. setup a user data directory which is nfs mounted, readable and writable by a normal user

> cd BHS
> ls -ldZ .
drwxrwxr-x. boriss boriss system_u:object_r:nfs_t:s0       .

Note the "nfs_t".

2. Run chrome:

> google-chrome --user-data-dir=.
Trace/breakpoint trap (core dumped)

What is the expected behavior?
Ideally, google-chrome should start successfully.

If for some reason the directory specified with "user-data-dir" cannot or should not be written to, chrome should detect this and exit gracefully, without dumping core.

What went wrong?
Seems like the part of google-chrome which is responsible for creating the directories .config and .cache cannot roperly handle a user-writable directory, which has a non-standard security context like "system_u:object_r:nfs_t"

Did this work before? N/A 

Chrome version: 67.0.3396.62 (Official Build) (64-bit)  Channel: stable
OS Version: Linux santaclara 3.10.0-862.3.2.el7.x86_64 #1 SMP Mon May 21 23:36:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Flash Version: 29.0.0.171

There are three cases to compare.

1) chrome dumps core when started with user-data-dir pointing to a directory which is writeable by a user, but has security context "system_u:object_r:nfs_t"

2) chrome works normally when started with user-data-dir pointing to a directory which is writeable by a user and has a more traditional security context, like "unconfined_u:object_r:user_home_t:s0"

3) chrome exits gracefully, when started with user-data-dir is not writeable by a normal user, say the root directory "/"

I have provided test outputs for each of the three scenarios in the attached file.
 

Deleted: google-core1.txt 2.6 KB

google-core1.txt 2.6 KB View Download