Обсуждение: Another user complaint regarding visibility of pg_catalog data
Hey,
This comes up every so often (including today on Discord) and I keep having trouble figuring out where to point people for our official assertion and explanation for why anyone with a login can view routine bodies, view specifications, and comments.
Apparently I griped about this a while ago and it fell on deaf ears:
Is this something we just don't want to go into detail within our documentation, or just no one has cared enough to write something up (beyond my first draft back then) and form it into a patch?
David J.
On Tue, Nov 7, 2023 at 12:28 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
Is this something we just don't want to go into detail within our documentation, or just no one has cared enough to write something up (beyond my first draft back then) and form it into a patch?
I've gone and added an FAQ entry for this at least so I can post a link to that in the future.
I'm not married to the title or content but wanted to get something out there while my mind was engaged on the topic.
David J.
On Tue, 2023-11-07 at 12:28 -0700, David G. Johnston wrote: > This comes up every so often (including today on Discord) and I keep having trouble > figuring out where to point people for our official assertion and explanation > for why anyone with a login can view routine bodies, view specifications, and comments. > > Is this something we just don't want to go into detail within our documentation, > or just no one has cared enough to write something up (beyond my first draft back > then) and form it into a patch? I am not sure if we can and want to document the "why" (this does not really belong into the technical documentation), but the fact that most catalog tables can be read by PUBLIC is worth documenting. Perhaps here: https://www.postgresql.org/docs/current/catalogs.html When people ask my "why?", I tend to answer "why not?". It is not a security problem, in my opinion. Every user is allowed to know that I have a table "purchase" with a column "credit_card_nr". As long as the permissions are set correctly, that is no problem. Any attempt to hide that information is at best "security by obscurity". Yours, Laurenz Albe
On Wednesday, November 8, 2023, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
When people ask my "why?", I tend to answer "why not?". It is not a security
problem, in my opinion. Every user is allowed to know that I have a table
"purchase" with a column "credit_card_nr". As long as the permissions are set
correctly, that is no problem. Any attempt to hide that information is at best
"security by obscurity".
The typical answer is some variant of trade secrets. Though wanting to store private info in a comment has some merit too.
David J.
On Wed, 2023-11-08 at 05:31 -0700, David G. Johnston wrote: > On Wednesday, November 8, 2023, Laurenz Albe <laurenz.albe@cybertec.at> wrote: > > When people ask my "why?", I tend to answer "why not?". It is not a security > > problem, in my opinion. Every user is allowed to know that I have a table > > "purchase" with a column "credit_card_nr". As long as the permissions are set > > correctly, that is no problem. Any attempt to hide that information is at best > > "security by obscurity". > > The typical answer is some variant of trade secrets. Though wanting to store > private info in a comment has some merit too. Don't keep your trade secrets in database identifiers or database function code. But if somebody is nervous about that, they can have their own database. Why share a database with users you don't trust? Yours, Laurenz Albe