Fail to load system keyring on Mac OS version 8.1

[martinrm77]

Please note that security bugs or issues should be reported to security@pgadmin.org.

Describe the bug

After upgrading to version 8.1 it will not load my system keyring. It keeps asking for password, and asking for password, again and again. If I type wrong password it says failed password, if I type correct password it asks again.

To Reproduce Install pgAdmin 4 v8.0 on Mac OS. Create server connetions. Upgrade to v8.1 Try to start pgAdmin 4 and enter login password to open system keyring

Steps to reproduce the behavior:

1. Start pgAdmin 4
2. Enter requested login password in the prompt
3. Go to 2 for a password loop.

Expected behavior

Should just open up pgadmin 4 without a prompt for password as I am already logged in and the system keyring is available.

Error message

No error message, just a repeating password prompt.

Screenshots

Desktop (please complete the following information):

• OS: Mac OS Sonoma
• Version: 14.2.1 (23C71)
• Mode: Desktop
• Browser (if running in server mode): N/A
• Package type: DMG

Additional context

[nikhil-mohite]

Hi @martinrm77 ,

I am unable to reproduce the issue with the upgrade and normal installation, can you please provide the steps or a short video recording?

[barbalex]

I have the exact same issue. I simply downloaded and installed the pgadmin4-8.1-arm64.dmg. From that moment on it is unusable.

I had to:

• reinstall v8.0
• re-enter password twice

...then it worked again.

[ROSeaboyer]

As someone else with the same issue, I upgraded to 8.1 and saw the issue immediately. At this point, I downgraded back to 8.0, got the pop-up a single time with 8.0, and then access to my Keychain remained (including across closing/reopening pgadmin). This is using both the arm64 and x86-64 builds.

[ShedPlant]

I also saw this opn Mac OS Sonoma 14.2.1 and rolled back to pgadmin4 8.0 😞

[JordanXtern]

I have the same issue, 8.1 (via brew), asks for my keychain password in an loop, no matter how many times I enter it. Downgrading to 8.0 (via dmg) fixes the issue.

[mheironimus-rgare]

I saw the same issue on macOS Sonoma 14.2.1 with pgAdmin 4 v8.1. Downgrading to v8.0 resolved the issue for me as well.

[andrew-parsons-janus]

Same issue. I installed 8.1 via the ARM .dmg. FWIW, it looks like I may have installed 8.0 via Homebrew, but forgot.

EDIT: resolved by downgrading to pgAdmin 4 8.0 via .dmg

[hwalker]

Same issue here. To reproduce, try installing 8.0 (ARM), then add some servers with saved passwords, then upgrade to 8.1 (ARM). Keep getting a popup that says:

Python wants to use your confidential information stored in "pgAdmin4" in your keychain. To allow this, enter the "login" keychain password.

Have to roll back to 8.0 in order to use the application.

[JuanMiranda]

Same issue here. SONOMA 14.2.1 - x86 build.

[thestelz]

@nikhil-mohite I'm having the same issue and I have a screen recording of it below:

https://github.com/pgadmin-org/pgadmin4/assets/1774502/9d508d13-4fdc-4c12-8adb-c197a6591d40

MacOS Ventura 13.5.1 (M2) pgAdmin4: 8.2

Downloaded pgadmin4-8.2-arm64.dmg

My steps to replicate:

1. Have 7.8 installed
2. Upgrade to 8.1
3. Have the issue described above, then see that 8.2 was just released
4. Update to 8.2 (the above screen recording was using 8.2)

[nikhil-mohite]

This is an issue while accessing the keychain in macOS, A Similar issue is already logged in Python's keyring(https://github.com/jaraco/keyring) library that pgAdmin is using. issue

[adityatoshniwal]

Hi @thestelz, How many servers do you have? And how many of them have saved passwords?

[thestelz]

@adityatoshniwal I have 10 servers all with saved passwords. I took a look at the keyring issue above and read that it isn't a loop, but asks each time for each saved password. After I read that I reinstalled 8.2 and entered my password 10 times and clicked allow all each time. After I did that everything appears to be working as expected now.

[mazar]

This is an issue while accessing the keychain in macOS, A Similar issue is already logged in Python's keyring(https://github.com/jaraco/keyring) library that pgAdmin is using. issue

If it's an issue with keychain in macOS, how come downgrading to v8.0 fixes it?

[hwalker]

I tested this on new version 8.2 (ARM) that just came out on Jan 9, 2024. (Upgraded from 8.0 to 8.2)

Now, if you hit "Deny" on the keychain popup, it then asks you for your master password. When you enter this, another popup immediately asks you for your Pgadmin master password. When you enter this, it seems to work.

When you reboot the application, the keychain popup comes back, and you have to hit deny again and enter your master password again.

At least you don't have to roll it back now, but it's still not working correctly...

[nikhil-mohite]

I tested this on new version 8.2 (ARM) that just came out on Jan 9, 2024. (Upgraded from 8.0 to 8.2)

Now, if you hit "Deny" on the keychain popup, it then asks you for your master password. When you enter this, another popup immediately asks you for your Pgadmin master password. When you enter this, it seems to work.

When you reboot the application, the keychain popup comes back, and you have to hit deny again and enter your master password again.

At least you don't have to roll it back now, but it's still not working correctly...

If pgAdmin is unable to use the KeyChain on macOS (When you click on the Deny button on the permissions dialog it will be unable to use KeyChain) it will ask for the master password and will use that to store the server passwords if the user selects Save Password checkbox when connecting to the server, and it will not use KeyChain to store the passwords.

[nikhil-mohite]

This is an issue while accessing the keychain in macOS, A Similar issue is already logged in Python's keyring(https://github.com/jaraco/keyring) library that pgAdmin is using. issue

If it's an issue with keychain in macOS, how come downgrading to v8.0 fixes it?

The issue is when the Python binary updates (or a new virtual environment is created), You will receive a popup asking for a login/keychain password. It will ask for permission per record it will try to access from KeyChain. If you have 3 records it will ask 3 times to allow you to access the keychain each per record.

You can check the access in KeyChain by Opening the KeyChain application and selecting any entry from KeyChain for pgAdmin, right-clicking and selecting Get info for more details, and going to the Access Control tab can see all the entries that allow for access to the specific record in KeyChain, so if you have already allowed KeyChain for pgAdmin 4 v8.0 that entry is already present the Access Control so it will not ask to allow KeyChain access again and due to that it is working fine if you downgrade pgAdmin to version 8.0.

[miskr-instructure]

There is a more severe problem with this - apps must not expect the Mac user to know their "login" keychain password. The MacOS API allows apps to add entries into the keychain without ever prompting the user for their keychain password, but it will prompt the user when the secret is read by a non-allowlisted app or by the human user themselves via the Keychain UI.

My Macbook is managed by corporate IT and my Sign-On password is apparently not my keychain password. I lost access to all secrets saved by pgadmin, probably permanently because downgrading hasn't recovered the saved passwords (I get past the popup but have to re-enter all the passwords).

I think the correct solution would be one of these:

1. let users choose whether to use key store at all
   • if they say no, use master password solution like before (7.x versions?)
   • if they say yes, make a prompt for them where have to prove they know their login keychain password before proceeding (if they don't have access to it due to IT policies, then don't let them choose this option, or they lock themselves out like me)
2. Only store the master password in keychain, encrypt individual passwords the same way they were encrypted before keychain got integrated. This way if the MacOS keychain craps the bed, the user will only need to enter their master password manually for pgAdmin to work as normal - no dozens of annoying prompts and lockout/downgrade needed.

Other chromium-based apps (VS Code, Google Chrome) seem to be doing something similar to option 2 by the way - they only create one item in the keychain called "[...] Safe Storage" (though they aren't using it via a python script but directly).

[thekeviv]

I'm having this same issue with version 8.2 today and downgraded back to 8.0.

[tauhidul35]

It will ask to enter the correct password for each saved server. You must enter the correct password as many times as your saved password. I had 15 saved servers before updating the software. I had to enter the password 30 times, and now it is working fine.

[yogeshmahajan-1903]

This is behaviour enforced by Mac itself. For every saved server, once it will ask for password.

[miskr-instructure]

@yogeshmahajan-1903 can pgAdmin project provide the option to disable the usage of MacOS Keychain at least? This is a UX issue and will happen every time pgAdmin upgrades the python binary in future releases. It's not even just having to enter the password dozens of times, but also losing your data if you don't have admin access to the keychain (can easily happen if you don't have high privileges on your MacOS).

[mheironimus-rgare]

@yogeshmahajan-1903 - Are you sure this issue cannot be addressed? It is not an issue for 8.0. It only started happening in 8.1. That implies something changed in 8.1 that caused it to start happening.

[nuno]

Same here

[miskr-instructure]

Are you sure this issue cannot be addressed? It is not an issue for 8.0.

It can be addressed in the ways I suggested to them earlier, by changing how pgAdmin uses the MacOS keystore. It just seems that the maintainers do not want to make changes to that, based on how this ticket got closed abruptly without any deeper reasoning.

It only started happening in 8.1. That implies something changed in 8.1 that caused it to start happening.

They most likely upgraded the embedded python binary between 8.1 and 8.0. The issue will not happen for users who did a fresh install of 8.1 without upgrading, obviously.

If I am right, this will happen in the future whenever the user upgrades their pgAdmin and it contains yet another new python version (which could happen like a few times a year). We all transparently got opted into using MacOS keystore around June 2023 or so (https://github.com/pgadmin-org/pgadmin4/issues/5123) with no way to opt out.

[adityatoshniwal]

Are you sure this issue cannot be addressed? It is not an issue for 8.0.

It can be addressed in the ways I suggested to them earlier, by changing how pgAdmin uses the MacOS keystore. It just seems that the maintainers do not want to make changes to that, based on how this ticket got closed abruptly without any deeper reasoning.

It only started happening in 8.1. That implies something changed in 8.1 that caused it to start happening.

They most likely upgraded the embedded python binary between 8.1 and 8.0. The issue will not happen for users who did a fresh install of 8.1 without upgrading, obviously.

If I am right, this will happen in the future whenever the user upgrades their pgAdmin and it contains yet another new python version (which could happen like a few times a year). We all transparently got opted into using MacOS keystore around June 2023 or so (#5123) with no way to opt out.

@miskr-instructure It is a replacement to master password which most users didn't want to enter. Keeping both master password and keychain makes it extremely complex to maintain. pgAdmin do have a DISABLED_LOCAL_PASSWORD_STORAGE config, but it is not mentioned anywhere in docs as we encourage users to move away from master password. Using keychain to store passwords is not something which only pgAdmin does. Many other applications does the same way and is a standard practice. We're exploring how we can improve this further.

[miskr-instructure]

Using keychain to store passwords is not something which only pgAdmin does. Many other applications does the same way and is a standard practice.

You're totally right, however other apps I've seen do it differently in two ways:

• the executable accessing the keychain is the initial process started by clicking in Applications (=the browser wrapper in case of pgAdmin), not a bundled/embedded daemon process (a python binary in case of pgAdmin)
• the app stores a single master secret in key store, which makes it less tedious in case access to key chain is lost for some reason, since the user only needs to provide that master secret manually

We're exploring how we can improve this further.

Thank you for the consideration!

[kbrown]

should be re-opened. just ran into this today. downgrading.

[adityatoshniwal]

should be re-opened. just ran into this today. downgrading.

Downgrading won't help. Its a one time "allow" loop.

[theskillwithin]

This is super annoying

[andrec93p]

I'm on macOS Sonoma, and after upgrading and downgrading to v8.0 multiple times because of this issue, I tried looking a bit more into it with v8.3.

It turns out the loop is not actually endless: as someone suggested above, the application is asking for your password for every server you set up. I tried providing my password and hitting "Always allow" every time the prompt popped up. After 20-something times, pgAdmin finally stopped and it seems to work properly now even after a quit and restart.

Still very annoying, but at least I can stay on the latest version.

[SiriusBits]

Same issue for me (on 8.2). I never saved the pw in Keychain so this was totally unexpected.

[cah-brandon-trebbien]

Can confirm... just keep typing in password 2x number of connections and eventually it will open. I'm on 8.1

[adityatoshniwal]

Same issue for me (on 8.2). I never saved the pw in Keychain so this was totally unexpected.

It should not actually. If nothing is saved then it will not ask.

[55jr55]

macOS Sonoma 14.3 pgAdmin 8.3, same issue

[miketwenty1]

Pretty annoying issue, I got it working by: killing the app, deleted app, nuked ~/.pgadmin directory, reinstalled, and then it worked.

[adityatoshniwal]

This is how Chromium does it:

1. Chromium stores passwords in a local SQLite database called “Login Data” ('/home/setevoy/.config/chromium/Default/Login Data')
2. If gnome-keyring or KWallet are installed then Chromium will encrypt passwords in its database using a generated password which will be stored in such a keyring
3. In other case and if Secret Service is not active at all – passwords will be kept “as is”, plain text Here keyring access is required only once to get the encryption key. It is similar to master password, only difference being the user need not to enter anything - it is taken care.

I suggest we change our code to follow a similar approach. It will also remove code complexity as we already have master password implementation. Only change will be that master password will auto generated, and stored in keyring.

[miskr-instructure]

That sounds nice.

Please do not forget to make it possible to recover from the keystore entry being unavailable/deleted, by allowing users to provide the master key/password directly to the app. This implies it should be possible to set a specific master key/password (that is also stored in keystore), instead of it being a completely random value.

[adityatoshniwal]

That sounds nice.

Please do not forget to make it possible to recover from the keystore entry being unavailable/deleted, by allowing users to provide the master key/password directly to the app. This implies it should be possible to set a specific master key/password (that is also stored in keystore), instead of it being a completely random value.

@miskr-instructure Majority of the users didn't like/want to enter master password. The reason keyring was introduced is to skip typing master password. So I'm not sure if we're going to re-introduce master password back. pgAdmin will behave just like any other app which allows saving password.

[miskr-instructure]

pgAdmin will behave just like any other app which allows saving password.

The difference is that other chromium-based apps access their keyring from a process spawned from the main executable (ie. the one that is launched by MacOS when we open the "app"), not from a different embedded executable (python) subprocess. This is almost certainly the reason for the keyring popups after the upgrades too (=MacOS considering a different embedded python binary as a completely separate program).

So if you are thinking of completely removing master password, the random password/key should be accessed from the pgAdmin chromium process , not from the embedded python subprocess. This seems difficult to pull off though, considering pgAdmin's design, but it is how every other electron/chromium solution does it to my knowledge (and they do not have keystore prompts after upgrades).

[adityatoshniwal]

The difference is that other chromium-based apps access their keyring from a process spawned from the main executable (ie. the one that is launched by MacOS when we open the "app"), not from a different embedded executable (python) subprocess. This is almost certainly the reason for the keyring popups after the upgrades too (=MacOS considering a different embedded python binary as a completely separate program).

I understand your concern. The difference between Chromium and pgAdmin here is, chromium autofills the password in the password input boxes and doesn't directly use it. pgAdmin however uses the server password to connect. For that, python process has to get the password. UI won't help. It won't be an issue unless there is a change in the Python version of the embedded binary which doesn't happen on every release. What we're trying here is, if it asks for keyring access then it should only be once. Not for every server.

[miskr-instructure]

I mean, the pgAdmin backend could prompt the front-end to fetch the master password/key on its behalf one time per application start, similarly to how it did so for master password (I assume, since there the frontend was asking for the user to enter it, then it must have been forwarded to the backend).

[adityatoshniwal]

I mean, the pgAdmin backend could prompt the front-end to fetch the master password/key on its behalf one time per application start, similarly to how it did so for master password (I assume, since there the frontend was asking for the user to enter it, then it must have been forwarded to the backend).

Interesting approach, basically going back to master password but instead of asking the user get it from system keyring from the front end. We'll need to try more on this, whichever works best and compatible across multiple platforms.

[miskr-instructure]

Thanks for considering it!

One other minor benefit of that approach would be that if you check in key chain app, the listed application in "Access Control" would say "pgAdmin" (executable/app name), not "python". That would be more intuitive.

[adityatoshniwal]

@miskr-instructure I suspect even that would ask for keyring access once you replace the pgAdmin 4 version just like python version right?

[miskr-instructure]

I doubt it would prompt, because then all the electron/chromium apps would run into the issue as well?

I have never encountered prompts with Slack/Zoom/Chrome/VSC after updates, even though all of those have a key chain entry and are based on chromium (and their chromium executable does get updated by their occasional auto-updates).

The only other difference I can think of between those apps and pgAdmin (other than the embedded executable) would be that those apps self-trigger their updates as opposed to the user reinstalling from a .dmg file. However if that were the cause, then every pgAdmin update should have caused the prompts, but only 8.1 did, not 8.0.

[johndennismpls]

➕ same issue

[juanmantelli]

same issue

[kevinlacaille]

Uninstalling, nuking ~/.pgadmin, then reinstalling worked for me.

OS: 14.3.1 pgadmin version: 8.5

[adityatoshniwal]

I checked the feasibility of accessing keychain from front end but unfortunately the front end container - NWjs doesn't have any API to access it. We're thinking of porting to Electron which will allow to do this.