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

Issue 600720 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

All saved passwords periodically disappear

Reported by enigma2...@gmail.com, Apr 5 2016

Issue description

Chrome Version       : Version 49.0.2623.108 Built on Ubuntu 14.04, running on LinuxMint 17.2 (64-bit)
URLs (if applicable) : n/a
Other browsers tested:
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
     Safari:
    Firefox: OK
         IE:

What steps will reproduce the problem?
(1) Unknown
(2)
(3)

What is the expected result?
Passwords are saved

What happens instead?
All saved passwords disappear every few days

Please provide any additional information below. Attach a screenshot if
possible.

I have not been able to correlate anything I am doing to when the saved passwords vanish.  I have upgraded chromium several times and the issue continues to occur so it is not related to a single version.  

 
Cc: kavvaru@chromium.org
Components: UI>Browser>Passwords
Labels: Needs-Feedback
enigma2175@ Thanks for the issue

Unable to reproduce the issue on windows 7,Linux Ubuntu 14.04 using chrome version 49.0.2623.110.Able to see the saved passwords after few days without any issues.

Request you please try the issue by upgrading chrome to latest stable and check the issue on new profile.If the issue still persists please provide us any specific sites you are seeing this issue frequently to triage the issue further.

Thanks,
Cc: dvadym@chromium.org
My guess is that they disappear when your Linux password manager is locked.
enigma2...@ Could you please check that the system keyring (it's Linux encrypted password storage) is not locked? For this could you please run a program seahorse from commandline, and there should be on the left of the opened window the list with existing storages. Could you please check whether "Login" item is locked (there should be a lock icon)? If it's locked, you can unlock it (from a context menu) and try to restart Chrome. Please let me know if it helps.
Running seahorse shows the "Login" item is unlocked.  I can see entries on the right that correspond with my saved passwords.  I did lock and then unlock the Login item and it seemed to work as expected so there doesn't appear to be an issue with that.  
OK, I am getting closer to the source of the issue.  Thanks for the pointer to the password manager dvadym and battre!  

On this computer I either run chromium on display :0 locally or in a VNC session on display :1 if I'm remote.  When I checked seahorse in the VNC session the login password manager WAS locked.  However, even if I manually unlock it I can still not see passwords in chromium, although I can see the entries in seahorse. 

If I import the passwords from Firefox when I'm remote I can see and use the passwords normally, even after stopping and starting chromium several times.  However, if I open the browser locally and try to view the passwords, it shows nothing (not even the help text that shows when there are no passwords) then after 60-120 seconds the passwords show up.  Once I can see the passwords locally if I start the browser in the remote session I can no longer see any passwords (and it DOES show the help text).  After that point the passwords will always show in the local session and not show in the VNC session unless I re-import the password list in the remote session.  

If I close the browser during the 60-120 seconds it takes to load the password page locally after importing remotely then the browser process hangs and doesn't respond to SIGINT.  My guess is there is some sort of contention going on between the two login sessions when trying to access the local password manager.  Is there anything I can do so that both sessions have access to the password list in chromium?


Project Member

Comment 6 by sheriffbot@chromium.org, Apr 7 2016

Labels: -Needs-Feedback Needs-Review
Owner: kavvaru@chromium.org
Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: OS-Linux
Owner: ----
"dvadym@" can you please look into the issue based on comment#5.

Comment 8 by dvadym@chromium.org, Apr 25 2016

Labels: -Needs-Review
 enigma2...@ Thanks for comprehensive explanation. It looks like local and remote sessions have some contentions with access to keyring. I'm not sure that Chrome can do something with it, Chrome knows nothing about different sessions. It sounds like a bug in keyring. 

We are planning a refactoring of a password storage on Linux and it should mitigate this problem.

And it seems that during 60-120 seconds Chrome is waiting for response from keyring and that's the reason why it hangs on closing. It's definitely bad, we need make some better handling of such situations, namely not to hang DB thread on requests that could last so long. I'm leaving this bug open for fixing this issue.

Comment 9 by vabr@chromium.org, May 31 2016

Status: WontFix (was: Unconfirmed)
I filed bug 616085 for the exit delay issue described by dvadym@ in #8.

The bug to migrate off Keyring for password storage is issue 571003.

Sign in to add a comment