API for Managing pg_hba and postgresql.conf

From: Andrew Satori <dru(at)druware(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: API for Managing pg_hba and postgresql.conf
Date: 2008-08-14 20:33:59
Message-ID: 7E3E27CC-E453-4475-821A-70810F86C3CF@druware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Looking at the list history, I see this has been discussed in the
past, but it has been long enough that perhaps it is time to revisit it.

It would appear from my own support queues, that one of the most
prevalent issues with PostgreSQL installations is not a functional
one, but an administrative one. For obvious reasons, the secure by
default installation is the correct choice, but it presents a
problem. With the proliferation of PostgreSQL onto platforms where
security isn't natural, there are hurdles that have to be dealt with.

What I'm seeing is a default installation protects the Data directory
properly, but in so doing means that altering the configuration files,
pg_hba.conf and postgresql.conf require database administrators, who
should not necessarily have a level of rights to become superuser at
the file system level to alter the mentioned files.

Rather than change the fundamental file layout or location, I would
propose that we expose an API or Schema in the database to better
allow manipulation of these configuration structure from within
PostgreSQL. This would allow a DBA to make changes to the
configuration without the need to be a machine administrator, or even
to run with escalated privilege at the OS level.

My concern over tackling this is that of security.

What would be the appropriate way to protect this API.

Should it be a collection of functions or s a schema?

Should it be part of the INFORMATION_SCHEMA?

Should it be an entirely different schema, say CONFIGURATION_SCHEMA?

Should the Schema or functions be restricted to a specific database
(say postgres) rather than part of every database?

Since most changes would require a SIGHUP, should the server process
itself be alter to allow for a dynamic restart from within the
environment?

While I have opinions and have tinkered with the idea a bit, I'll be
the first to admit that this is functionality that needs to be
discussed and structure in a generally supportable way rather than a
platform specific hack, so I'm looking for thoughts and opinions of an
educated variety.

A huge portion of the motivation here is to allow for easy to
graphical administration interfaces, making the system more
approachable, and to make remote administration of these files less
cumbersome.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2008-08-14 21:05:56 Re: proposal sql: labeled function params
Previous Message Jan Urbański 2008-08-14 20:27:55 Re: gsoc, oprrest function for text search take 2