Re: Insufficient attention to security in contrib (mostly)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: josh(at)agliodbs(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Insufficient attention to security in contrib (mostly)
Date: 2007-08-27 19:45:02
Message-ID: 7106.1188243902@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> pgrowlocks tells you about row lock states, which maybe is not that
>> interesting for security, but still it's information that one wouldn't
>> expect to be exposed to someone who isn't allowed to read the table.
>> I suppose knowing the number of live tuples might in itself be
>> sensitive information.

> Here I think the advantage of being able to run this as a non-superuser
> (and thus not have the superuser password on the client machine) outweighs
> any data which can be reverse-engineered from the lock information.

I have no objection to knocking this down to demanding only SELECT privs
on the table. It's hard to think that it is OK to be totally unsecured.

> Hmmm, we can't really require anything greater than SELECT permission for
> dbsize.

That's OK for individual tables, but we have no equivalent concept for
whole databases or tablespaces. What do you propose for them?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2007-08-27 20:35:38 Re: MSVC build system
Previous Message Decibel! 2007-08-27 19:35:37 Re: Problem with recent permission changes commits