Re: allowing privileges on untrusted languages

On 1/11/13 10:25 AM, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> It turned out that actually getting rid of lanpltrusted would be too
>> invasive, especially because some language handlers use it to determine
>> their own behavior.
>
>> So instead the lanpltrusted attribute now just determined what the
>> default privileges of the language are, and all the checks the require
>> superuserness to do anything with untrusted languages are removed.
>
> Hmm ... that worries me a bit. It seems like system security will now
> require being sure that the permissions on the language match the
> lanpltrusted setting. Even if the code is right today, there's a lot
> of scope for future oversights with security implications. Don't know
> what we could do to mitigate that.

I think altogether this patch does not introduce any more reasons "to be
careful" then any other security-related patch. The ACL stuff is
already spread out over too many places, and you could argue that this
patch reduces some of that surface area.

> In particular, have you thought carefully about upgrade scenarios?
> Will a dump-and-restore of a pre-9.3 installation end up with safe
> language privileges?

Untrusted languages in pre-9.3 installations cannot have any privileges,
because GRANT denies that. If you grant some anyway (e.g., set the
trusted bit, grant, re-remove trusted bit), then, well, you get what you
asked for, expect now it actually works.

> In the same vein, I'm worried that the proposed change in pg_dump will
> do the wrong thing when looking at a pre-9.3 server. Is any
> server-version-dependent behavior needed there?

That shouldn't be a problem for the same reasons.

What might actually be a problem in this area is that, AFAICT, pg_dump
does not save privileges granted to objects in extensions.