Re: Hiding GUC variables from non-superusers - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Hiding GUC variables from non-superusers
Date
Msg-id 1098481788.20926.112.camel@localhost.localdomain
Whole thread Raw
In response to Hiding GUC variables from non-superusers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2004-10-22 at 21:09, Tom Lane wrote:
> Pursuant to prior discussion, I have added a flag to guc.c that marks
> certain GUC variables as not to be shown to non-superusers.  For the
> moment it's just set on variables related to the server's filesystem
> layout, such as the recently added data_directory and config_file
> variables.  But now that we have it, I am wondering if it shouldn't
> be set on other potentially security-related variables.  For instance,
> knowing exactly what logging the DBA is doing or not doing might be of
> assistance to a blackhat user.  On the other hand, it's a bit pointless
> to block viewing of any USERLIMIT variables, since the user can discover
> by experimentation what their settings are; and most of the
> logging-level variables are USERLIMIT.  (Maybe that whole concept is a
> bad idea and should be rethought.  Why exactly should a non-privileged
> user be able to adjust logging level either up or down?  Cranking it out
> to the max could be seen as a crude form of DOS attack...)
> 

Complete agreement. Anything that can't be set should be invisible.

Setting logging high or even checking that logging is set high could be
the precursor to a DoS attack via repeated accesses.

Looking at memory sizes might be a way to spot small, poorly setup
systems.

> I am strongly tempted to mark "archive_command" as well.  Unless we want
> to revisit the USERLIMIT idea, there's not anything else I see that
> looks worth marking.
> 

Yes, definitely archive_command should be.

I'd still prefer a master GUC for archive_mode = on, which would be user
visible. ......I'll wear you down ....we've got years yet, ;-)

-- 
Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: timestamp with time zone a la sql99
Next
From: Simon Riggs
Date:
Subject: Re: [PATCHES] ARC Memory Usage analysis