login_LoginSuccess should clean up after itself |
||||
Issue descriptionautotest should clean up the profile that gets created when login completes. Presence of the data in stateful caused security_StatefulPermissions ( crbug.com/876988 ) to fail sporadically leading to many sheriff hours of diagnostics.
,
Aug 31
I don't know who owns the login tests these days, but perhaps dchan@ does. Why do we believe that the login test was wrong? It feels like the real problem is that security_StatefulPermissions is assuming that there's no device profile on the DUT. Tests shouldn't assume that. Also, what changed that we're only now discovering this? Both of those tests have been around a really long time. Did one of them change, or did the product?
,
Aug 31
,
Aug 31
Things seem to get mounted into cryptohome now? https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1127665
,
Aug 31
> Things seem to get mounted into cryptohome now? > https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1127665 OK. That still feels like the problem here isn't the login test adding stuff it shouldn't, but rather the security test making unjustified assertions about what the file system is allowed to contain (most particularly, what the file system is allowed to contain given new cryptohome behavior).
,
Aug 31
Is there a way that we can guarantee that login_LoginSuccess always runs before security_StatefulPermissions? If we could produce a consistent failure, that would've been easier to debug. Also, it would make sense to login before checking stateful as they are apparently intertwined.
,
Aug 31
> Is there a way that we can guarantee that login_LoginSuccess always > runs before security_StatefulPermissions? No. And that doesn't feel like a good fix anyway. Someone needs to put forth an explanation as to why it's right or wrong for the login test not to delete any user profile that it creates and/or explain why it's right or wrong that the security test fails if there's a user profile present. If we can make a case for at least one of those, it would go a long way towards identifying what's _really_ the right fix.
,
Sep 5
I've done what I know how for this bug. I don't know who should own it, and without more data, I can't even say whether I believe that the proposed fix (or any other fix) is correct. |
||||
►
Sign in to add a comment |
||||
Comment 1 by skau@chromium.org
, Aug 29