Protection of debugging options

Started by Peter Eisentrautover 25 years ago3 messages
#1Peter Eisentraut
peter_e@gmx.net

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#1)
Re: Protection of debugging options

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

#3Peter Eisentraut
peter_e@gmx.net
In reply to: Tom Lane (#2)
Re: Protection of debugging options

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