Re: inconsistent owners in newly created databases?

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Thomas Swan <tswan(at)idigx(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: inconsistent owners in newly created databases?
Date: 2004-05-03 08:29:41
Message-ID: Pine.LNX.4.58.0405031021450.9381@sablons.cri.ensmp.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Dear Thomas,

> * create the database with the new owner specified.
>
> -- As a superuser in the newly created database
> update pg_am set amowner = {userid}
> update pg_class set relowner = {userid}

You don't want to update ownership of tables in system schemas.

> update pg_conversion set conowner = {userid}
> update pg_namespace set nspowner = {userid}

As for SCHEMAs, I would not do that for system schemas
(pg_%, information_schema)...

> update pg_opclass set opcowner = {userid}
> update pg_operator set oprowner = {userid}
> update pg_proc set proowner = {userid}

I'm not sure system functions owner should be change. Also, call handlers
for languages should not change owner.

> update pg_type set typowner = {userid}
>
> Are there any security problems that this would cause? Perhaps these
> should be done by the system automatically.

I think that something along the line you describe should be done by the
system. However database creation does not actually connect to the new
database, the template base directory is simply copied with a "cp -r".

It is unclear to me at the time when these updates should be performed.
After the createdb? Deferred to the first connection to the database?

--
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2004-05-03 08:56:14 Re: ANALYZE locks pg_listener in EXCLUSIVE for long
Previous Message Philip Warner 2004-05-03 08:21:19 Re: ANALYZE locks pg_listener in EXCLUSIVE for long