From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Sandro Santilli <strk(at)keybit(dot)net>, pgsql-bugs(at)postgresql(dot)org, peter_e(at)gmx(dot)net |
Subject: | Re: cache lookup failed from empty plpythonu function |
Date: | 2013-01-25 21:00:27 |
Message-ID: | 20130125210026.GA24655@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2013-01-25 15:40:46 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > quite possibly doesn't work if copied from here but for quicker viewing:
>
> > CREATE OR REPLACE FUNCTION "foo():
> > pass
>
> > import os
> > os._exit(1)
> > def "() RETURNS void LANGUAGE plpythonu AS $$pass$$;
>
> > Yep:
> > LOG: server process (PID 29317) exited with exit code 1
>
> Ooops. Good thing plpython is already superuser-only, or this would be
> a security problem. So should we stop including the SQL function name
> in the python name?
I don't think it's worth it and having something recognizable in there
is useful in (python) backtraces.
I am pretty sure I could do the same in the function source with some
trickery even without the function being executed just because python
also executes stuff during parsing, so I don't think it would buy
enough.
We probably should care about it if there were a trusted plpython (so
you couldn't cause an incomplete function being called or whatever) but
I don't see that happening anytime soon.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-01-25 22:01:47 | Re: BUG #6528: pglesslog still referenced in docs, but no 9.1 support |
Previous Message | Tom Lane | 2013-01-25 20:40:46 | Re: cache lookup failed from empty plpythonu function |