New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 878688 link

Starred by 1 user
Status: WontFix
Owner:
vapier@chromium.org
Closed: Oct 4
Cc:
mqg@chromium.org
derat@chromium.org
█ stevefung@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

crash-reporter incorrectly determines primary user

Project Member Reported by mnissler@chromium.org, Aug 29 
crash-reporter calls session_manager's RetrieveActiveSessions DBus method with the assumption that the first account ID in the reply is the primary user (i.e the one that started the user session, not a subsequently added user).

This assumption is incorrect on many levels:
1. session_manager doesn't return the entries in a particular order (it could though given the return value type is a{ss} - see https://chromium.git.corp.google.com/chromiumos/platform2/+/2f1122fbfd60787a2caf0e5a1f32bc160935aba8/login_manager/dbus_bindings/org.chromium.SessionManagerInterface.xml#378 ).
2. The DBus bindings on the crash reporter side decode the reply into a std::map, which ignores the order.

As a result, crash-reporter will always consider the user with the account ID that sorts first lexicographically to be the primary user, which is incorrect in general.

Comment 1 by vapier@chromium.org, Aug 29

Components: -OS>Systems OS>Systems>CrashReporting
does this really matter ?  it's still stored in a user encrypted profile.  you might argue that one account might have a stronger password and be the "preferred" one, but there shouldn't be any difference otherwise.

crash_sender will walk all profiles and upload the reports regardless of which profile it's located in.

if there is no API to get the "primary" account, then this is just how it behaves now :).

Comment 2 by mqg@google.com, Aug 31

Cc: mqg@chromium.org

Comment 3 by mqg@google.com, Aug 31 

Hi all - 

I'm actually making an effort to add dbus api for primary user, because biod needs to know primary user. http://b/77568272 has the details.

A CL is here: https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1195730

What do ppl think of this added dbus api? How it works internally in session_manager we can review / revise.

Comment 4 by vapier@chromium.org, Aug 31 

in an ideal world, we wouldn't even be using the primary profile for user crashes.  we'd have some way to associate the "active profile" with the crash we're currently processing.  for processes under the chronos acccount, that's probably not worth the effort.  for chrome crashes, it probably would be possible to have chrome pass that user hash down to us directly on the command line, but i'm not sure how feasible that is in the chrome world.

Comment 5 by mnissler@chromium.org, Oct 4

Status: WontFix (was: Assigned)
Fair points regarding crash reporter not caring much about which user account it is that it dumps the crash information to. In fact, crash_reporter code doesn't mention any assumption about the first user being primary. So let's close this as WAI.

Btw., I don't think we associate a crash with a specific user in general (all users share the browser process FWIW), so that isn't a great option either.

Comment 6 by vapier@chromium.org, Oct 4 

it might be even more of a moot point with go/project-dent

you might be able to argue that different cryptohome mounts are "better protected" based on account-specific policies (like how we require google.com to always be the primary), in which case there is a slight improvement when it comes to data at-rest.

once Mengqi's APIs land, we'll prob cut over the crash-reporter code to use it since it's just as easy as what we already have
►

Sign in to add a comment