On 03/11/2017 03:15 PM, Michael Paquier wrote: > Yeah but it can be called as well while the application is calling > PQgetResult() and still looping until it gets a NULL result. Not sure > if this is a use-case to worry about, but sending a query to the > server in PQencryptPassword() could as well break some applications.
I was suggesting sending the query outside of PQencryptPassword() in order to determine what method should be passed as a new argument to PQencryptPassword(). > PQencryptPassword() is used for CREATE/ALTER ROLE commands, so > actually wouldn't it make sense to just switch PQencryptPassword to > handle SCRAM if at some point we decide to switch the default from md5 > to scram? So many questions. As long as we support more than one method it would seem to me we need a way to determine which one we want to use and not only default it, don't we? Apologies if this has already been discussed -- I was not able to follow the lengthy threads on SCRAM in any detail. >> I guess a related problem might be, do we have a SQL visible way to >> determine what method is used by the current password for a given role? > > Nope. We are simply looking at a function doing a lookup at pg_authid > and then use get_password_type() to check which type of verifier is > used... Or have the type of verifier as a new column of pg_authid, > information that could be made visible to any users with column > privileges. What happens if the user does not have privs for pg_authid? E.g. if I want to change my own password what happens if the default is one method, and my password uses the other -- now I cannot change my own password using \password? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
signature.asc
Description: OpenPGP digital signature
