Re: Protection of debugging options - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Protection of debugging options
Date
Msg-id 26751.960312525@sss.pgh.pa.us
Whole thread Raw
In response to Protection of debugging options  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Protection of debugging options
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Every Joe User can currently run
>     env PGOPTIONS='-d99 -tpa -tpl -te' psql
> and stuff the server log with relative garbage that he will never be able
> to see anyway.

> As I don't believe it feasible to do superuser checking before the options
> parsing it seems to me that these option in particular (and -s as well)
> need to be "secure". Those desiring to diagnose transient problems can use
> SET debug_level, etc. which does have a superuser check in place.

I object loudly --- this would be a major pain in the rear end.

Currently it's possible to trace the queries issued by an application by
the simple expedient of setting PGOPTIONS="-d something" before starting
the app; no cooperation from the app is necessary.  To get the same
functionality via SET you'd need to teach the app about the SET command,
set up some sort of command line switch or environment variable for it
to look at, etc etc.

Furthermore, I do not think that "unprivileged users stuffing the log"
is an adequate reason for taking away this functionality.  A person who
wants to cause trouble by bloating the log will certainly be able to do
so anyway.

Finally, where did you get the idea that the equivalent SET vars should
be superuser restricted?  I object to that, too.  By doing that you've
essentially removed *any* way to trace an app on demand, unless one is
willing to run the app as superuser.  This is taking concern for
security too far --- if anything, you are making the system *less*
secure by forcing people to run things as superuser just to find out
what they're doing.
        regards, tom lane


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: Odd release numbers for development versions?
Next
From: Tom Lane
Date:
Subject: Re: Re: ODBC configure