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