Обсуждение: Protection of debugging options

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. For
permanent debug level changes there's of course this shiny new
configuration file and the HUP signal.

Comments?

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

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

Tom Lane writes:

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

It sure would. But it's a trade off between that and log stuffing, I
suppose.

> Finally, where did you get the idea that the equivalent SET vars should
> be superuser restricted?

Nowhere. The ones that were adopted from pg_options had a general
superuser restriction. Any that might be new just played along. The idea
was to leave it as is at first and then over time look at each option in
detail.

Okay, so all logging/debugging options available to the public.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden