pgadmin4
pgadmin4 copied to clipboard
Fail to load system keyring on Mac OS version 8.1
Please note that security bugs or issues should be reported to [email protected].
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:
- Start pgAdmin 4
- Enter requested login password in the prompt
- 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
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?
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.
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.
I also saw this opn Mac OS Sonoma 14.2.1 and rolled back to pgadmin4 8.0 😞
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.
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.
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
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.
Same issue here. SONOMA 14.2.1 - x86 build.
@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:
- Have 7.8 installed
- Upgrade to 8.1
- Have the issue described above, then see that 8.2 was just released
- Update to 8.2 (the above screen recording was using 8.2)
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
Hi @thestelz, How many servers do you have? And how many of them have saved passwords?
@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.
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?
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...
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.
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. issueIf 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.
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:
- 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)
- 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).
I'm having this same issue with version 8.2 today and downgraded back to 8.0.
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.
This is behaviour enforced by Mac itself. For every saved server, once it will ask for password.
@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).
@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.
Same here
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.
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.
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!
should be re-opened. just ran into this today. downgrading.
should be re-opened. just ran into this today. downgrading.
Downgrading won't help. Its a one time "allow" loop.
This is super annoying