Re: [WIP] ALTER ... OWNER TO ... CASCADE

From: Vladimir Borodin <root(at)simply(dot)name>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [WIP] ALTER ... OWNER TO ... CASCADE
Date: 2016-02-16 08:23:14
Message-ID: 50C7D221-99D2-4BD0-9999-D9BA78A47E20@simply.name
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 15 февр. 2016 г., в 19:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> написал(а):
>
> Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
>>> So basically, a generic CASCADE facility sounds like a lot of work to
>>> produce something that would seldom be anything but a foot-gun.
>
>> DELETE FROM or TRUNCATE could be a foot-gun too, but it's not a reason to
>> remove tham. I faced with problem when I tried to change owner of datadase with
>> all objects inside. Think, this feature could be useful although it should
>> restricted to superuser obly.
>
> That's a pretty weak argument, and I do not think you have thought through
> all the consequences. It is not hard at all to imagine cases where using
> this sort of thing could be a security vulnerability. Are you familiar
> with the reasons why Unix systems don't typically allow users to "give
> away" ownership of files? The same problem exists here.
>
> To be concrete about it:
>
> 1. Alice does, say, "CREATE EXTENSION cube".
>
> 2. Bob creates a security-definer function owned by himself, using a
> "cube"-type parameter so that it's dependent on the extension.
> (It needn't actually do anything with that parameter.)
>
> 3. Alice does ALTER EXTENSION cube OWNER TO charlie CASCADE.
>
> 4. Bob now has a security-definer function owned by (and therefore
> executing as) Charlie, whose contents were determined by Bob.
> Game over for Charlie ... and for everyone else too, if Charlie is
> a superuser, which is not unlikely for an extension owner.
>
> The only way Alice can be sure that the ALTER EXTENSION is safe is if
> she manually inspects every dependent object, in which case she might
> as well not use CASCADE.

Seems to be a problem that should be addressed.

>
> Moreover, the use case you've sketched (ie, change ownership of all
> objects inside a database) doesn't actually have anything to do with
> following dependencies. It's a lot closer to REASSIGN OWNED ... in
> fact, it's not clear to me why REASSIGN OWNED doesn't solve that
> use-case already.

Sometimes I hit the following. You have created a database and schema inside it from the superuser (i.e. postgres). Than you want to change ownership of whole database to another user (i.e. alice), but only this database, not all other objects in all other databases. It seems that REASSIGN OWNED doesn’t solve this already.

>
> I remain of the opinion that this is a terrible idea.
>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
May the force be with you…
https://simply.name

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-02-16 08:50:33 Re: Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
Previous Message Andres Freund 2016-02-16 08:13:09 Re: Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?