Hiding GUC variables from non-superusers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Hiding GUC variables from non-superusers
Date: 2004-10-22 20:09:52
Message-ID: 18434.1098475792@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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_file
data_directory
dynamic_library_path
external_pid_file
hba_file
ident_file
krb_server_keyfile
log_directory
log_filename
preload_libraries
unix_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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kenneth Marshall 2004-10-22 20:09:55 Re: ARC Memory Usage analysis
Previous Message Jan Wieck 2004-10-22 19:35:49 Re: ARC Memory Usage analysis