Re: OWNER TO on all objects - Mailing list pgsql-hackers

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>> This brings up a question for Chris, which is whether he's implemented
>> this in a way that forces the decision at pg_dump time, or whether
>> it is made during pg_restore.

> I've implented it exactly like comments are implemented.  I just created 
> a dumpOwner() function that adds an archive entry to the current object. 
>    It appears in the pg_dump.c basically wherever a dumpComment() 
> appears, but always before the dumpAcls() if there is one.

I think this is wrong, primarily because it's gonna be seriously
incompatible with existing dump files.  The existing technique is
that each TOC entry says who owns the object.  You should use that
information and not have to rely on new additions to the file format.

> * I fix ALTER OWNER to allow it to work if you are NOT a superuser, but 
> ARE the existing owner.

No, you don't.  That allows non-superusers to give away object
ownership, which is well-established as a security hole; Unix
filesystems stopped doing it years ago.

>   - How does the above point affect full dumps that include schema and 
> data?  In my proposal, the copy commands will run as the user running 
> the script, not the table owner anymore.  Presumably, the user running 
> the script is a superuser.  Given that it is possible for a table owner 
> to revoke their own INSERT privilege on their table, the existing 
> behaviour is broken anyway.

This is why GRANT/REVOKE has to be postponed to the end.  I think it
would be a lot simpler and more reliable if you also postponed ALTER
OWNER.

> * Custom format dumps
>   - OK, I admit I have little experience with this format.

Then you have fundamentally failed to grok pg_dump, and you should
rethink everything you've done to date.  The way things work is that
EVERYTHING effectively goes through a custom dump.  pg_dump in text
mode is really pg_dump followed by pg_restore with the intermediate
TOC just kept in memory temporarily.  Therefore, any time you have done
something that you don't know how to convert into pg_restore behavior,
it's because you were hacking the wrong place.  Everything you need to
know about an object *must* go through the TOC representation and then
be converted to text at the restore side.

>   - With respect to Tom's question about restore-time option - how is it 
> different to now?? A that moment, we have the pg_restore -O option to 
> not restore the session auth commands - what needs to change?  I just 
> won't output the ALTER OWNER commands so everything will be owned by 
> whoever runs pg_restore.

I think there needs to be a restore-side switch that chooses whether
to emit ALTER OWNER or SET SESSION AUTH commands.  This is probably
just for pro-forma SQL compliance, unless Peter has some brilliant
insight about how to avoid ALTER OWNER.
        regards, tom lane