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