Re: inconsistent owners in newly created databases? - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: inconsistent owners in newly created databases?
Date
Msg-id Pine.LNX.4.58.0405031021450.9381@sablons.cri.ensmp.fr
Whole thread Raw
In response to Re: inconsistent owners in newly created databases?  (Thomas Swan <tswan@idigx.com>)
Responses Re: inconsistent owners in newly created databases?
List 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@cri.ensmp.fr


pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: ANALYZE locks pg_listener in EXCLUSIVE for long
Next
From: Philip Warner
Date:
Subject: Re: ANALYZE locks pg_listener in EXCLUSIVE for long