Issue metadata
Sign in to add a comment
|
cryptohome --action=mount_ex nukes cryptohome when given bad password |
||||||||||||||||||||||
Issue descriptionGoogle Chrome 59.0.3064.0 (Official Build) dev (64-bit) Revision 0 Platform 9438.0.0 (Official Build) dev-channel caroline What steps will reproduce the problem? 1. Give wrong password on a user account 2. Give correct password now What is the expected result? User should be able to sign-in What happens instead? Unable to sign-in even with correct password
,
Apr 7 2017
,
Apr 7 2017
,
Apr 7 2017
Jacob could you look at this at a priority? Thanks!
,
Apr 7 2017
,
Apr 7 2017
cryptohome is broken; running mount_ex with a bad password nukes the cryptohome. localhost ~ # ls /home/user/ a49056c07af34360a31a9cafdaefca5319bafdd3 localhost ~ # cryptohome --action=mount_ex --user=testuser838383@gmail.com Enter the password: error: CRYPTOHOME_ERROR_ACCOUNT_NOT_FOUND [cryptohome.MountReply.reply] { recreated: false sanitized_username: "a49056c07af34360a31a9cafdaefca5319bafdd3" } Mount failed. localhost ~ # ls /home/user/ localhost ~ #
,
Apr 7 2017
I have a theory. This specific line in the recent CL is probably causing it: https://chromium-review.googlesource.com/c/461345/3/cryptohome/crypto.cc#194 Let me verify that it is the root cause.
,
Apr 7 2017
It makes sense from the theoretical point of view: kTpmRetryFailNoRetry that happens if decrypting fails, now leads to CE_TPM_FATAL -> MOUNT_ERROR_FATAL. And if that happens, we re-create the cryptohome here: https://chromium.googlesource.com/chromiumos/platform2/+/master/cryptohome/mount.cc#419 Why it fails to be removed and recreated after that, that's a separate question (you should be able to login on the 2nd try, but the local data would be lost). But the original cause seems to be here. Verifying still, will submit a 1-line CL to delete that "case Tpm::kTpmRetryFailNoRetry:" line, if that theory is correct.
,
Apr 7 2017
Confirmed, submitting https://chromium-review.googlesource.com/c/471871/. Verified that it fixes the problem.
,
Apr 7 2017
,
Apr 7 2017
Reproduce "Issue/709659" on chrome 59.0.3064/CrOS 9438.0.0 - blaze, candy
,
Apr 7 2017
Should be reproducible on all boards with tpm 1.2 chips (2.0 follows a bit different path, so there it is not seen). The CL from comment#9 is on it's way to CQ.
,
Apr 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/5ffdcf1ceeb31a03fdd626187f377aa7268f94b5 commit 5ffdcf1ceeb31a03fdd626187f377aa7268f94b5 Author: Andrey Pronin <apronin@chromium.org> Date: Mon Apr 10 05:30:25 2017 cryptohome: don't treat kTpmRetryFailNoRetry as fatal crypto error When a wrong password is provided while mounting cryptohome, in TPM 1.2 case Tpm::kTpmRetryFailNoRetry is returned. If that error is converted to Crypto::CE_TPM_FATAL, cryptohome is recreated. And that's a bad outcome in response to a mistyped password. Don't treat this error as CE_TPM_FATAL thus. BUG= chromium:709547 TEST=Attempt to login with wrong password, then attempt to login with the right one. The 2nd attempt should succeed. Change-Id: Ie44b0a4c3f66545b31dab8a05994aee4ff62dac7 Reviewed-on: https://chromium-review.googlesource.com/471871 Tested-by: Andrey Pronin <apronin@chromium.org> Reviewed-by: Luigi Semenzato <semenzato@chromium.org> Commit-Queue: Andrey Pronin <apronin@chromium.org> [modify] https://crrev.com/5ffdcf1ceeb31a03fdd626187f377aa7268f94b5/cryptohome/tpm.h [modify] https://crrev.com/5ffdcf1ceeb31a03fdd626187f377aa7268f94b5/cryptohome/crypto.cc
,
Apr 10 2017
Marking as fixed for verification by test team
,
Apr 11 2017
Verified on ChromeOS 9449.0.0, 59.0.3065.0 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by sdantul...@chromium.org
, Apr 7 20172.8 MB
2.8 MB View Download