Re: Insufficient attention to security in contrib (mostly)
От | Tom Lane |
---|---|
Тема | Re: Insufficient attention to security in contrib (mostly) |
Дата | |
Msg-id | 7106.1188243902@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Insufficient attention to security in contrib (mostly) (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Insufficient attention to security in contrib (mostly)
|
Список | 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 по дате отправления: