Thread: dropdb to a remote host

dropdb to a remote host

From
Alex Avriette
Date:
when I do:

/usr/local/pgsql/bin/dropdb -h myhost -U myuser dbname

it complains that there isnt an entry in pg_hba.conf for 'template1', when i
rather explicitly told it to drop 'dbname'. am i missing something?

alex

--
alex j. avriette
perl hacker.
a_avriette@acs.org
$dbh -> do('unhose');

Re: dropdb to a remote host

From
Bruce Momjian
Date:
> when I do:
>
> /usr/local/pgsql/bin/dropdb -h myhost -U myuser dbname
>
> it complains that there isnt an entry in pg_hba.conf for 'template1', when i
> rather explicitly told it to drop 'dbname'. am i missing something?

You need to connect to template1 to do the dbname drop.  My guess is
that pg_database has been truncated somehow.  You can actually connect
to any database and do the command "DROP DATABASE dbname".


--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: dropdb to a remote host

From
Jason Earl
Date:
I believe that dropdb simply connects to template1 and issues the
"drop database" command.  If you don't have access to the template1
database then you can't drop other databases.

Jason

Alex Avriette <a_avriette@acs.org> writes:

> when I do:
>
> /usr/local/pgsql/bin/dropdb -h myhost -U myuser dbname
>
> it complains that there isnt an entry in pg_hba.conf for 'template1', when i
> rather explicitly told it to drop 'dbname'. am i missing something?
>
> alex
>
> --
> alex j. avriette
> perl hacker.
> a_avriette@acs.org
> $dbh -> do('unhose');
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

Re: dropdb to a remote host

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> ... You can actually connect
> to any database and do the command "DROP DATABASE dbname".

Any database *except* the one to be deleted.  dropdb defaults to using
template1 to issue the DROP.  My bet is that Alex mistakenly thought
it'd be a good idea to forbid connections to template1.

            regards, tom lane

Re: dropdb to a remote host

From
Bruce Momjian
Date:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > ... You can actually connect
> > to any database and do the command "DROP DATABASE dbname".
>
> Any database *except* the one to be deleted.  dropdb defaults to using

Yes, of course.  :-)

> template1 to issue the DROP.  My bet is that Alex mistakenly thought
> it'd be a good idea to forbid connections to template1.

Oh, that's probably how this happened.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: dropdb to a remote host

From
Bruce Momjian
Date:
> Well, yeah, this is how that happened. Could you please make a note in the
> pg_hba.conf for future releases indicating if you prohibit connections to
> template1 that certain commands (dropdb being one of them) will not work?

I have added this to pg_hba.conf.sample:

  # The superuser needs access to the 'template1' database because
  # it is used by a variety of PostgreSQL utility commands.

However, this glaringly shows how poor our user-specific authentication
is in pg_hba.conf.  You would have to create a password file with the
super user name in it and add that to the end of the template1 host line
to restrict just to superuser.  Quite cumbersome.

Hopefully in 7.3 we will be able to put usernames in pg_hba.conf.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: dropdb to a remote host

From
Alex Avriette
Date:
Well, yeah, this is how that happened. Could you please make a note in the
pg_hba.conf for future releases indicating if you prohibit connections to
template1 that certain commands (dropdb being one of them) will not work?

Thanks,
alex