| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: allowing privileges on untrusted languages |
| Date: | 2013-01-11 15:25:04 |
| Message-ID: | 8630.1357917904@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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?
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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-01-11 15:31:24 | Re: ToDo: log plans of cancelled queries |
| Previous Message | Andres Freund | 2013-01-11 15:19:30 | Re: foreign key locks |