Re: Can we have a new SQL callable function to get Postmaster PID?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Can we have a new SQL callable function to get Postmaster PID?
Date: 2021-02-03 21:57:14
Message-ID: 3992522.1612389434@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
> On 2/3/21 4:08 PM, Tom Lane wrote:
>> I'm disinclined to think that this is a good idea from a security
>> perspective. Maybe if it's superuser-only it'd be ok (since a
>> superuser would have other routes to discovering the value anyway).

> Is the postmaster PID really sensitive? Users with OS access can just
> list the processes, and for users without OS access / privileges it's
> mostly useless, no?

We disallow ordinary users from finding out the data directory location,
even though that should be equally useless to unprivileged users. The
postmaster PID seems like the same sort of information. It does not
seem like a non-administrator could have any but nefarious use for that
value. (Admittedly, this argument is somewhat weakened by exposing
child processes' PIDs ... but you can't take down the whole installation
by zapping a child process.)

I'm basically in the same place you are in your other response: the
question to ask is not "why not allow this?", but "why SHOULD we allow
this?"

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-02-03 22:03:14 Re: new heapcheck contrib module
Previous Message David Rowley 2021-02-03 21:31:12 Re: Tid scan improvements