On Wed, Jun 22, 2016 at 12:04 AM, Stephen Frost <sfr...@snowman.net> wrote: > Ugh. I would certainly rather not have yet another special, hard-coded, > bit of logic that magically makes things available to a superuser when > it's not available to regular users. > What that results in is the need to have a new default role to control > access to that column for the non-superuser case.
OK, we could always update system_views.sql to revoke all rights from public.. This ship has not sailed yet. > As for the password showing up, sorry, but we need a solution for *that* > regardless of the rest- the password shouldn't be exposed to anyone, nor > should it be sent and kept in the backend's memory for longer than > necessary. I'm not suggesting we've got that figured out already, but > that's where we should be trying to go. This connection string is stored in shared memory in WalRcvData, and that's the case for a couple of releases now, so it has already a high footprint, though I agree that making that available at SQL level makes it even worse. Looking at the code, as libpq does not link directly to libpqcommon, I think that the cleanest solution is to do something similar to wchar.c, aka split the parsing, deparsing routines that we are going to use in a file located in src/backend/, and then build libpq using it. Writing a patch for that would not be that complicated. What is stored in WalRcvData is then the connection string filtered of its password field, or we could just obfuscate it with ***. It may still be useful to the user to know that a password has been used. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
