On Mon, Dec 20, 2010 at 3:31 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: > > > But, if the script is run on the same machine as postgresql is on, the > scripts that check for changes could be compromised as well and then > you'd never know. > I agree, if the system has been compromised, nothing will prevent the scripts from being compromised. Hence why I am looking for alternatives. I consider the md5 script approach a poor approach, but it does meet the letter of the requirements set forth by the organization. > > Is there an alternative method of implementing such a requirement? Possibly > > one already incorporated into PostgreSQL? > > pgsql doesn't do any of that, but I'm sure you can roll your own so to > speak. I would tend to write some kind of nagios plugin that could be > called remotely that would notify you whenever it changes so you would > know as soon as a change occurred rather than later when trying to > restart the database during a midday outage while the boss screams > "get the system back up now! We're losing money!" > Thanks for clarifying that for me. Part of the requirement I'm working with requires "vendor documentation" stating if such a feature exists. Since there is no vendor documentation, they'll have to settle for my own documentation, backed up with a mailing list post. Writing my own plugin/module hasn't been ruled out. I wanted to make sure that I'm not re-inventing the wheel. In any approach to this, I will be including an override which will allow PostgreSQL to start despite failing the "trusted files" check. > Generally, if the db's been compromised, someone's already gotten to > an app server or two, and might be sniffing traffic anyway, so it's > likely a lost cause by then. Agreed. Unfortunately, I've been given specific requirements and I am obligated to fulfill those requirements, even if I don't agree those requirements are necessary. This is all in addition to an extensive OS lockdown script, as well as additional lockdown requirements for the database. I appreciate the help. I believe this is an excellent starting point to try and address this requirement. Ken -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
