And it was from Peter.
On Mon, Jan 27, 2014 at 8:20 PM, KONDO Mitsumasa
wrote:
At least, only postgres superuser can see pg_stat_statemnet view in old
version.
And you should change document at this sentences.
No, it was precisely the same situation in every way that matters; the
texts and o
Sorry, I forgot to add pgsql-commiters email adress. So I re-post our e-mail
discussion.
(2014/01/28 11:50), Peter Geoghegan wrote:
On Mon, Jan 27, 2014 at 6:31 PM, KONDO Mitsumasa
wrote:
No. I don't say root user is superuser. Executing initdb user will be
postgres superuser. But it can cha
On Mon, Jan 27, 2014 at 6:31 PM, KONDO Mitsumasa
wrote:
> No. I don't say root user is superuser. Executing initdb user will be
> postgres superuser. But it can change non-superuser after creating database.
Okay. I still don't understand what your point is, or how this patch
makes any worse what
On Mon, Jan 27, 2014 at 9:31 PM, KONDO Mitsumasa
wrote:
>> Why is your concern with pg_stat_statements after this patch in
>> particular?
>>
>> You'll need to serialize the file at least once before seeing it, but
>> then it's there for good (on old versions, before Magnus got annoyed
>> that that
On Mon, Jan 27, 2014 at 6:08 PM, Tom Lane wrote:
> "Timed just right"? I could see it possibly happening due to queryid
> collisions, but I'm not seeing how it would happen absent such a hash
> collision.
Consider what happens when there is a pg_stat_statements_reset() call
query after another q
(2014/01/28 11:07), Peter Geoghegan wrote:
On Mon, Jan 27, 2014 at 6:04 PM, KONDO Mitsumasa
wrote:
It is written in documents; "For security reasons, non-superusers are not
allowed to see the text of queries executed by other users." Is root user
superuser? And initdb user might change to non-s
KONDO Mitsumasa writes:
> (2014/01/28 10:23), Tom Lane wrote:
>> Also, current query texts are probably less interesting to an intruder
>> than the contents of the database itself, which is stored in the same
>> directory tree with the same permissions (0600) as the query-text file.
> Yes, that's
(2014/01/28 10:23), Tom Lane wrote:
> Peter Geoghegan writes:
>> On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
>> wrote:
>>> This patch has security problem that root can easily see the statement file
>>> in database cluster.
>
>> By default, we always serialize statements along with their qu
Peter Geoghegan writes:
> On Mon, Jan 27, 2014 at 5:34 PM, Andrew Dunstan wrote:
>> The query texts are particularly uninteresting since I assume the data
>> values in the query have already been mostly dissolved away by
>> pg_stat_statements.
> Actually, it is possible for the query string to s
On Mon, Jan 27, 2014 at 6:04 PM, KONDO Mitsumasa
wrote:
> It is written in documents; "For security reasons, non-superusers are not
> allowed to see the text of queries executed by other users." Is root user
> superuser? And initdb user might change to non-superuser after creating
> database clust
(2014/01/28 10:15), Peter Geoghegan wrote:
On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
wrote:
This patch has security problem that root can easily see the statement file
in database cluster.
By default, we always serialize statements along with their query
texts to disk on shutdown. Unti
On Mon, Jan 27, 2014 at 5:34 PM, Andrew Dunstan wrote:
> The query texts are particularly uninteresting since I assume the data
> values in the query have already been mostly dissolved away by
> pg_stat_statements.
Actually, it is possible for the query string to still have constants
if things ar
On Mon, Jan 27, 2014 at 5:23 PM, Tom Lane wrote:
> Root can certainly also look at query texts in shared memory, or for that
> matter in the local memory of any process. So can anybody else running as
> the postgres userid.
I think that the concern may have had something to do with a
MAC-centric
On 01/27/2014 08:23 PM, Tom Lane wrote:
Peter Geoghegan writes:
On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
wrote:
This patch has security problem that root can easily see the statement file
in database cluster.
By default, we always serialize statements along with their query
texts to
Peter Geoghegan writes:
> On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
> wrote:
>> This patch has security problem that root can easily see the statement file
>> in database cluster.
> By default, we always serialize statements along with their query
> texts to disk on shutdown. Until May of
On Mon, Jan 27, 2014 at 5:12 PM, KONDO Mitsumasa
wrote:
> This patch has security problem that root can easily see the statement file
> in database cluster.
By default, we always serialize statements along with their query
texts to disk on shutdown. Until May of 2012, pg_stat_statements
didn't bo
KONDO Mitsumasa writes:
> (2014/01/28 5:38), Tom Lane wrote:
>> Keep pg_stat_statements' query texts in a file, not in shared memory.
> This patch has security problem that root can easily see the statement file in
> database cluster.
What's your point? It's idle to imagine that root can't see
Hi,
(2014/01/28 5:38), Tom Lane wrote:
Keep pg_stat_statements' query texts in a file, not in shared memory.
This patch has security problem that root can easily see the statement file in
database cluster.
Is it OK or disscussed? If root user and operation user don't have access
privilege in t
Keep pg_stat_statements' query texts in a file, not in shared memory.
This change allows us to eliminate the previous limit on stored query
length, and it makes the shared-memory hash table very much smaller,
allowing more statements to be tracked. (The default value of
pg_stat_statements.max is
19 matches
Mail list logo
