Обсуждение: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Addtest for postmaster crash restarts.

Поиск
Список
Период
Сортировка

On 09/30/2017 10:32 PM, Andres Freund wrote:
> Hi,
>
> On 2017-09-30 22:28:39 -0400, Andrew Dunstan wrote:
>>>> But even after fixing that, there unfortunately is:
>>>>
>>>> static void
>>>> set_sig(char *signame)
>>>> {
>>>> …
>>>> #if 0
>>>>     /* probably should NOT provide SIGKILL */
>>>>     else if (strcmp(signame, "KILL") == 0)
>>>>         sig = SIGKILL;
>>>> #endif
>>>>
>>>> I'm unclear on what that provision is achieving? If you can kill with
>>>> pg_ctl you can do other nasty stuff too (like just use kill instead of
>>>> pg_ctl)?
>>
>> I put it in when we rewrote pg_ctl in C many years ago, possibly out of
>> a superabundance of caution. I agree it's worth revisiting. I think the
>> idea was that there's a difference between an ordinary footgun and an
>> officially sanctioned footgun :-)
> Heh.  I'm inclined to take it out. We could add a --use-the-force-luke
> type parameter, but it doesn't seem worth it.
>
>
>


I agree, but I think we need this discussed on -hackers. Does anyone
have an objection to allowing "pg_ctl kill KILL somepid"? As Andres
points out, in most places you can just call kill from the command line
anyway, so disallowing it is not really a security feature. Having it
would let us have portable crash restart tests.

cheers

andrew


-- 

Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 09/30/2017 10:32 PM, Andres Freund wrote:
>> Heh.  I'm inclined to take it out. We could add a --use-the-force-luke
>> type parameter, but it doesn't seem worth it.

> I agree, but I think we need this discussed on -hackers. Does anyone
> have an objection to allowing "pg_ctl kill KILL somepid"? As Andres
> points out, in most places you can just call kill from the command line
> anyway, so disallowing it is not really a security feature. Having it
> would let us have portable crash restart tests.

+1 for portable tests, but it still seems like something we don't want
to encourage users to use.  What do you think of leaving it out of the
documentation?
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2017-10-01 16:42:44 -0400, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > On 09/30/2017 10:32 PM, Andres Freund wrote:
> >> Heh.  I'm inclined to take it out. We could add a --use-the-force-luke
> >> type parameter, but it doesn't seem worth it.
> 
> > I agree, but I think we need this discussed on -hackers. Does anyone
> > have an objection to allowing "pg_ctl kill KILL somepid"? As Andres
> > points out, in most places you can just call kill from the command line
> > anyway, so disallowing it is not really a security feature. Having it
> > would let us have portable crash restart tests.
> 
> +1 for portable tests, but it still seems like something we don't want
> to encourage users to use.  What do you think of leaving it out of the
> documentation?

As far as I can tell we've not documented the set of acceptable signals
anywhere but the source. I think we can just keep it that way?

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


On 10/01/2017 04:48 PM, Andres Freund wrote:
> On 2017-10-01 16:42:44 -0400, Tom Lane wrote:
>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>> On 09/30/2017 10:32 PM, Andres Freund wrote:
>>>> Heh.  I'm inclined to take it out. We could add a --use-the-force-luke
>>>> type parameter, but it doesn't seem worth it.
>>> I agree, but I think we need this discussed on -hackers. Does anyone
>>> have an objection to allowing "pg_ctl kill KILL somepid"? As Andres
>>> points out, in most places you can just call kill from the command line
>>> anyway, so disallowing it is not really a security feature. Having it
>>> would let us have portable crash restart tests.
>> +1 for portable tests, but it still seems like something we don't want
>> to encourage users to use.  What do you think of leaving it out of the
>> documentation?
> As far as I can tell we've not documented the set of acceptable signals
> anywhere but the source. I think we can just keep it that way?


As documented it's in the help text:
   printf(_("\nAllowed signal names for kill:\n"));   printf("  ABRT HUP INT QUIT TERM USR1 USR2\n");


So we can leave it out of there. OTOH I'm not a huge fan of security by
obscurity. I guess this wouldn't be too bad a case.

cheers

andrew

-- 

Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2017-10-01 17:47:52 -0400, Andrew Dunstan wrote:
> 
> 
> On 10/01/2017 04:48 PM, Andres Freund wrote:
> > On 2017-10-01 16:42:44 -0400, Tom Lane wrote:
> >> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> >>> On 09/30/2017 10:32 PM, Andres Freund wrote:
> >>>> Heh.  I'm inclined to take it out. We could add a --use-the-force-luke
> >>>> type parameter, but it doesn't seem worth it.
> >>> I agree, but I think we need this discussed on -hackers. Does anyone
> >>> have an objection to allowing "pg_ctl kill KILL somepid"? As Andres
> >>> points out, in most places you can just call kill from the command line
> >>> anyway, so disallowing it is not really a security feature. Having it
> >>> would let us have portable crash restart tests.
> >> +1 for portable tests, but it still seems like something we don't want
> >> to encourage users to use.  What do you think of leaving it out of the
> >> documentation?
> > As far as I can tell we've not documented the set of acceptable signals
> > anywhere but the source. I think we can just keep it that way?
> 
> 
> As documented it's in the help text:
> 
>     printf(_("\nAllowed signal names for kill:\n"));
>     printf("  ABRT HUP INT QUIT TERM USR1 USR2\n");

Oh, hm. I'd looked above.


> So we can leave it out of there. OTOH I'm not a huge fan of security by
> obscurity. I guess this wouldn't be too bad a case.

I'd personally include it, given that we already allow and document
ABRT. There's no meaningful difference between the two.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andres Freund <andres@anarazel.de> writes:
> On 2017-10-01 17:47:52 -0400, Andrew Dunstan wrote:
>> So we can leave it out of there. OTOH I'm not a huge fan of security by
>> obscurity. I guess this wouldn't be too bad a case.

> I'd personally include it, given that we already allow and document
> ABRT. There's no meaningful difference between the two.

True.
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2017-10-01 18:01:27 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2017-10-01 17:47:52 -0400, Andrew Dunstan wrote:
> >> So we can leave it out of there. OTOH I'm not a huge fan of security by
> >> obscurity. I guess this wouldn't be too bad a case.
> 
> > I'd personally include it, given that we already allow and document
> > ABRT. There's no meaningful difference between the two.
> 
> True.

I'll push it that way then. Adapting a help text later is fairly
harmless.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers