From what I understand, crash_reporter is invoked directly by the kernel - it uses /proc/sys/kernel/core_pattern, set to |/sbin/crash_reporter --user=%P:%s:%u:%e.
Therefore is not spawn by init and its session keyring will not contain keyring 'dircrypt'.

We can avoid the problem by having the kernel save the crash dump in /var (encrypted) and then have a daemon (spun by init) move the crash into the /home/user crash directory.

crash dump generated by ARC++ does not have this problem, because the core dumper is running from the Android container. However, core_collector32 is also impacted.

I'm not sure if it's possible to avoid using core_pattern to launch crash_reporter, as it writes not only a core dump, but also a metadata file which contains info like the Chrome OS version and the executable name.

According to "man core", when the kernel launches a process specified by core_pattern, UID and GID will be root.
Isn't it feasible to let the root user have a user keyring?

+vapier who would be familiar with crash_reporter stuff

writing user dumps to /var is a non-starter.  it's explicitly part of our PII design that we don't write user data outside of the user's partition.

we will need to expose a method for crash-reporter to access the keyring.

We can solve the problem by using ioctl KEYCTL_JOIN_SESSION_KEYRING.

I was able to join a session keyring, verifying keyctl issue that ioctl:

# keyctl session test   << create a shell, use the session keyring test.
Joined session keyring: 490130339
# keyctl rdescribe @s
keyring;0;0;3f130000;test
# keyctl setperm @s 0x3f1b0000  << allow other process with the same UID to search this ring, in addition to view and read.

.. in another shell:
# cat /proc/keys
0a3538e5 I--Q---     1 perm 1f3f0000     0 65534 keyring   _uid_ses.0: 1
1d36cba3 I--Q---     2 perm 3f1b0000     0     0 keyring   test: empty
3b0aa9df I--Q---     2 perm 1f3f0000     0 65534 keyring   _uid.0: empty
(the keyring test is seen and searchable)
keyctl session test cat /proc/keys
Joined session keyring: 490130339
0a3538e5 I--Q---     1 perm 1f3f0000     0 65534 keyring   _uid_ses.0: 1
1d36cba3 I--Q---    10 perm 3f1b0000     0     0 keyring   test: empty
3b0aa9df I--Q---     2 perm 1f3f0000     0 65534 keyring   _uid.0: empty
(the keyring 490130339, aka 0x1d36cba3, aka test is joined).

Given in c/331340 we set the session keyring with KEY_POS_SEARCH and assuming crash_reporter is launched as root, it could work.

that sounds like it should work.  the issue of discoverability is still there ... how will crash-reporter know which keyring to join ?

if we could get some process to write it out somewhere in /run/ that crash-reporter would read, that'd work.

we do run a crash-reporter --init step.  can a process discover which keyrings it has access to ?  it could take care of writing out the keyrings to join ...

I talked with Gwendal offline about this.  The keyring name is going to be hardcoded (as "dircrypt") so we can just use that in crash-reporter.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/portage-stable/+/f7acd444490a5e3e2576da767c9400fd6031be6d

commit f7acd444490a5e3e2576da767c9400fd6031be6d
Author: Chirantan Ekbote <chirantan@chromium.org>
Date: Thu Jan 26 22:53:54 2017

keyutils: upgraded package to upstream

Upgraded sys-apps/keyutils to version 1.5.9-r3 on amd64, arm

BUG= chromium:672397 
TEST=built and deployed on peach_pit and cave with no issues

Change-Id: Id495d4ff97dcc3628b4cf38b234233c9d8cbafd6
Reviewed-on: https://chromium-review.googlesource.com/433534
Commit-Ready: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[add] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/sys-apps/keyutils/files/keyutils-1.5.9-endian-check-1.patch
[rename] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/sys-apps/keyutils/keyutils-1.5.9-r3.ebuild
[add] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/sys-apps/keyutils/files/keyutils-1.5.9-disable-tests.patch
[add] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/sys-apps/keyutils/files/keyutils-1.5.9-endian-check-2.patch
[add] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/sys-apps/keyutils/files/keyutils-1.5.9-header-extern-c.patch
[rename] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/metadata/md5-cache/sys-apps/keyutils-1.5.9-r3

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/portage-stable/+/f7acd444490a5e3e2576da767c9400fd6031be6d

commit f7acd444490a5e3e2576da767c9400fd6031be6d
Author: Chirantan Ekbote <chirantan@chromium.org>
Date: Thu Jan 26 22:53:54 2017

keyutils: upgraded package to upstream

Upgraded sys-apps/keyutils to version 1.5.9-r3 on amd64, arm

BUG= chromium:672397 
TEST=built and deployed on peach_pit and cave with no issues

Change-Id: Id495d4ff97dcc3628b4cf38b234233c9d8cbafd6
Reviewed-on: https://chromium-review.googlesource.com/433534
Commit-Ready: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[add] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/sys-apps/keyutils/files/keyutils-1.5.9-endian-check-1.patch
[rename] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/sys-apps/keyutils/keyutils-1.5.9-r3.ebuild
[add] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/sys-apps/keyutils/files/keyutils-1.5.9-disable-tests.patch
[add] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/sys-apps/keyutils/files/keyutils-1.5.9-endian-check-2.patch
[add] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/sys-apps/keyutils/files/keyutils-1.5.9-header-extern-c.patch
[rename] https://crrev.com/f7acd444490a5e3e2576da767c9400fd6031be6d/metadata/md5-cache/sys-apps/keyutils-1.5.9-r3

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/c546f23af90d34af8db6ef7bb5683c594c9c93d5

commit c546f23af90d34af8db6ef7bb5683c594c9c93d5
Author: Chirantan Ekbote <chirantan@chromium.org>
Date: Wed Jan 25 20:48:49 2017

crash-reporter: Add dependency on keyutils

Once ext4-based encryption is enabled, crash_reporter will need to use the
keyutils library to join the session keyring.

BUG= chromium:672397 
TEST='emerge-cave crash-reporter' and 'emerge-peach_pit crash-reporter' complete
      successfully

Change-Id: I64ae75c59a9c2130f2cd941a0ec0d667d5abe10a
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433177
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/c546f23af90d34af8db6ef7bb5683c594c9c93d5/chromeos-base/crash-reporter/crash-reporter-9999.ebuild

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

commit 4960f1c939dc11ba90a2e01f0316f9027ad43d4c
Author: Chirantan Ekbote <chirantan@chromium.org>
Date: Wed Jan 25 20:16:05 2017

crash: Join session keyring when collecting a user crash

Once ext4-based directory encryption is enabled, the encryption keys will be
stored in a session keyring created by init.  Since most processes get started
by init they will naturally inherit the keyring from init.  However,
crash_reporter is directly invoked by the kernel to record a core dump so it
doesn't automatically start with access to the keyring.

Have the crash_reporter attempt to join the session keyring before writing out
the core dump.  It may be the case that the session keyring does not exist,
which would imply that ext4 encryption is not enabled on that device so we don't
need to join the session keyring anyway.  In the case the core dump should still
be stored successfully as before.

BUG= chromium:672397 
TEST=manual
On a cave with ext4 encryption enabled and on a peach_pit without ext4
encryption enabled, run the following steps:
- start python
- in a separate shell kill the python process with 'kill -11'
- grep crash_reporter /var/log/messages and confirm that the core dump was
  successfully written out
CQ-DEPEND=CL:433177,CL:433534

Change-Id: I76541950238d1a6f83e9a13ffd32254a468829fd
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433098
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/4960f1c939dc11ba90a2e01f0316f9027ad43d4c/crash-reporter/user_collector_base.h
[modify] https://crrev.com/4960f1c939dc11ba90a2e01f0316f9027ad43d4c/crash-reporter/user_collector_base.cc
[modify] https://crrev.com/4960f1c939dc11ba90a2e01f0316f9027ad43d4c/crash-reporter/crash-reporter.gyp
[modify] https://crrev.com/4960f1c939dc11ba90a2e01f0316f9027ad43d4c/common-mk/common.gypi