Re: Insufficient attention to security in contrib (mostly) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Insufficient attention to security in contrib (mostly)
Date
Msg-id 7106.1188243902@sss.pgh.pa.us
Whole thread Raw
In response to Re: Insufficient attention to security in contrib (mostly)  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Insufficient attention to security in contrib (mostly)  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.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


pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: Problem with recent permission changes commits
Next
From: Magnus Hagander
Date:
Subject: Re: MSVC build system