On 1/11/13 10:25 AM, Tom Lane wrote: > Peter Eisentraut <pete...@gmx.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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers