RE: Backing up postgresql databases
От | Tim Frank |
---|---|
Тема | RE: Backing up postgresql databases |
Дата | |
Msg-id | 20010320.18282168@cr625228-a.ktchnr1.on.wave.home.com обсуждение исходный текст |
Ответ на | RE: Backing up postgresql databases (Michael Ansley <Michael.Ansley@intec-telecom-systems.com>) |
Список | pgsql-admin |
Mike, From a different perspective I toyed around briefly with the idea of creating a user called "backup" that would merely have SELECT permissions on all tables in all databases in order to perform a pg_dump or pg_dumpall. This works fine for a pg_dump as it does a single database at a time. The problem was that I couldn't figure out a way to automatically set SELECT permissions for the backup user when a new table was created in the database. You can't set a default value in the pg_class table nor create a trigger on insert as it complains about "can't modify a system catalogue". Maybe there is some other way to get around that, and I would be more than happy to hear comments on this. The other problem I found was that when using pg_dumpall it dumps all the database usernames/passwords so the "backup" user would need select permissions on pg_shadow which contains all of the usernames/passwords. Well, I kinda quit right there as far as using this restricted "backup" user for pg_dumpall because if it can select all users/passwords from the database then storing this combination in a shell script/environment variable isn't any more secure. Sure, it takes one more step to get ALL usernames/passwords, but that doesn't seem to be worth the effort. Thinking about it now and seeing a shell script somebody posted a little while ago to do a vacuum and pg_dump it might not be such a bad idea to go back to the "backup" user with SELECT only permissions on the tables. Just not sure how to set the permissions on newly created tables by default, maybe it just has to be manually. I would greatly appreciate comments on this idea and if it is worth anything. I've teetered back and forth for some time. Tim Frank Original Message dated 20/03/01, 6:48:08 AM Author: Michael Ansley <Michael.Ansley@intec-telecom-systems.com> Re: RE: [ADMIN] Backing up postgresql databases: Is there any reason why programs like this could not be given a simple properties file which contains the username and password. This file could then be passed on the command line, but nobody (other than, say, root, or postgres) would have access to it at all. I've seen a number of systems use this type of solution, and although it appears superficially useless (am I opening myself to be shot down or what ;-), the security of the file system creates (as far as I can see) reasonable safety. Just my ¬25... MikeA >> -----Original Message----- >> From: Thierry Besancon [mailto:Thierry.Besancon@prism.uvsq.fr] >> Sent: 20 March 2001 08:34 >> To: Tim Frank >> Cc: pgsql-admin@postgresql.org >> Subject: Re: [ADMIN] Backing up postgresql databases >> >> >> Dixit Tim Frank <tfrank@registrar.uoguelph.ca> (le Tue, 20 >> Mar 2001 00:14:11 GMT) : >> >> » Have your shell script do >> » >> » export PGUSER=username >> » export PGPASSWORD=password >> » >> » before you run pg_dumpall in the same script. The >> user/pass would most >> » likely have to be a superuser to have access to all >> databases (this is >> » also not guaranteed depending on your pg_hba.conf). Make >> the script >> » read/execute by root but not by anyone else and it will >> help a tiny bit >> » with security. >> >> Using something like "ps -e" shows the environment variables so it is >> as unsecure as giving the password on the commande line. >> >> Thierry >> >> ---------------------------(end of >> broadcast)--------------------------- >> TIP 6: Have you searched our list archives? >> >> http://www.postgresql.org/search.mpl >> _________________________________________________________________________ This e-mail and any attachments are confidential and may also be privileged and/or copyright material of Intec Telecom Systems PLC (or its affiliated companies). If you are not an intended or authorised recipient of this e-mail or have received it in error, please delete it immediately and notify the sender by e-mail. In such a case, reading, reproducing, printing or further dissemination of this e-mail is strictly prohibited and may be unlawful. Intec Telecom Systems PLC. does not represent or warrant that an attachment hereto is free from computer viruses or other defects. The opinions expressed in this e-mail and any attachments may be those of the author and are not necessarily those of Intec Telecom Systems PLC. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ________________________________________________________________________ __
В списке pgsql-admin по дате отправления: