Обсуждение: Hiding GUC variables from non-superusers

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...)

Right now what I have marked are

config_filedata_directorydynamic_library_pathexternal_pid_filehba_fileident_filekrb_server_keyfilelog_directorylog_filenamepreload_librariesunix_socket_directory

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.

Comments, opinions?
        regards, tom lane

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