david.g.johnston@xxxxxxxxx wrote:bryn@xxxxxxxxxxxx wrote: Thanks again, David. Yes... the section "5.7. Privileges" is essential reading. And I do see what I'd missed now. I broke it into bullets to make it (very much) easier for me at least to parse. « PostgreSQL grants privileges on some types of objects to PUBLIC by default when the objects are created. * No privileges are granted to PUBLIC by default on tables, table columns, sequences, foreign data wrappers, foreign servers, large objects, schemas, or tablespaces. For other types of objects, the default privileges granted to PUBLIC are as follows: * CONNECT and TEMPORARY (create temporary tables) privileges for databases; * EXECUTE privilege for functions and procedures; * USAGE privilege for languages and data types (including domains). The object owner can, of course, REVOKE both default and expressly granted privileges. (For maximum security, issue the REVOKE in the same transaction that creates the object; then there is no window in which another user can use the object.) Also, these default privilege settings can be overridden using the ALTER DEFAULT PRIVILEGES command. » (I'd already been burned by the fact that EXECUTE is granted to PUBLIC on newly-created functions and procedures.) The paragraph describes very surprising behavior in the present era of "secure by default". The sentence "For maximum security..." at the end emphasizes this and has you go to some effort (CREATE and REVOKE in the same txn) to undo the "insecurity by default" paradigm. I s'pose that compatibility on upgrade means that nothing can change here. Might it be possible to give the paragraph more prominence (like make it a note and start it with "WARNING" in large letters). And to x-ref it from the CREATE DATABASE section? And from the "pg_hba.conf" section? And correspondingly from the CREATE accounts for the objects of the other types? |