New issue
Advanced search Search tips

Issue 874088 link

Starred by 0 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Feature



Sign in to add a comment

crash-reporter: make unclean shutdowns into crash reports

Project Member Reported by vapier@chromium.org, Aug 14

Issue description

currently crash-reporter has a unclean shutdown collector, but it only processes metrics

we now independently have a /mnt/stateful_partition/shutdown_stateful_umount_failure flag which contains extra debug info to try and triage what's unclean, but it doesn't get uploaded or otherwise generate a crash/metric event.  this means we have to wait for users to file feedback reports or QA team to notice an issue, and then for us to try and reproduce it locally so we can recreate the logs.  but even after that, we don't have a way of knowing whether we've really fixed the issue other than "people stopped complaining".

we should combine these and use the extended debug info as the contents of the crash report

tnagel: can you check the privacy aspects ?  here's the code in question:
https://chromium.googlesource.com/chromiumos/platform2/+/release-R69-10895.B/init/chromeos_shutdown
- this code normally runs only after all users have been logged out
- we explicitly kill all processes with open files to stateful & user mounts (which means all user processes should be killed)
- only after all of that, and if we try to unmount the stateful partition, if it fails we collect:
  - the current set of mounts
    - if the kernel crashed, it could have a user mount to a USB stick and we'll see the LABEL the user has given it
    - but this info is also collected in a lot of other reports already
  - the device mapper info which has basic metadata about the mount and its runtime status
    - the stateful partition (although once we migrate to ext4 encryption, this would go away)
    - *not* user cryptohome mounts as they should be ext4 encryption now
    - any components the system has mounted (although they should have all been unmounted already)
  - all open files on the system still (excluding network details)
    - all user and stateful related processes should have been killed twice over by now

so basically, the only time we might collect PII is if the kernel crashed or failed in some way, and that's precisely the time when we want it as we need to see what crashed or failed to unmount so we can track it back and fix it.
 
Labels: Review-Privacy

Comment 2 Deleted

Project Member

Comment 3 by chrome-privacy-bot@chromium.org, Sep 10

Dear ,

This review has now been inactive for over 3 days. Could you please take appropriate steps to finish the review?

Your friendly privacy review bot.
Labels: LaunchIssue-NA
Owner: tnagel@chromium.org
Status: Assigned (was: Available)
Assigning to tnagel@, since the question in Comment #1 was directed at him.
Project Member

Comment 5 by chrome-privacy-bot@chromium.org, Nov 5

Dear tnagel,

This review has now been inactive for over 3 days. Could you please take appropriate steps to finish the review?

Your friendly privacy review bot.

Sign in to add a comment