Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Hm. If you incorrectly mark your function as IMMUTABLE even though it
> > has side effects then the planner may indeed collapse this. Does the
> > planner know it can't collapse views if the underlying tables aren't
Greg Stark <[EMAIL PROTECTED]> writes:
> Hm. If you incorrectly mark your function as IMMUTABLE even though it
> has side effects then the planner may indeed collapse this. Does the
> planner know it can't collapse views if the underlying tables aren't
> accessible to the user?
There are no cases
Mike Mascari writes:
> 2. Issue a query like:
>
> SELECT *
> FROM view_of_salaries_based_on_current_user
> WHERE my_side_effect_function_that_inserts_into_a_temp_table(salary,
> employee);
That's just exactly equivalent to
SELECT *
FROM (select *
from all_salaries
whe
Josh Berkus wrote:
Mike,
I think most people coming from any other enterprise-class RDBMS
environment will be surprised that they cannot use VIEWs to provide
user-specific views on data. I could be wrong, but I'd put money on it...
Well, I'd say that giving regular users the "create" permi
Mike,
> I think most people coming from any other enterprise-class RDBMS
> environment will be surprised that they cannot use VIEWs to provide
> user-specific views on data. I could be wrong, but I'd put money on it...
Well, I'd say that giving regular users the "create" permission on your
datab
> 2. Issue a query like:
>
> SELECT *
> FROM view_of_salaries_based_on_current_user
> WHERE my_side_effect_function_that_inserts_into_a_temp_table(salary,
> employee);
An SRF will guarantee an execution order and work for security purposes,
but getting your function with side effects to run earl
Mike Mascari wrote:
Correct, as the vulnerability exists within the 'SQL' language as well.
The only difference is that enabling plpgsql by default changes it from
a leak to a full blown flood.
How does it make any difference at all?
-Neil
---(end of broadcast)
Andrew Dunstan wrote:
Mike Mascari wrote:
but the side effect function will only run (unless you set it with
security definer) with the privileges of the caller - it won't grant
visibility to things that user can't otherwise see.
If the visibility is determined by view definitions, such as usi
Mike Mascari wrote:
Neil Conway wrote:
Mike Mascari wrote:
People who use views to achieve row security, which is a rather
common paradigm, cannot allow users to create functions with side
effects.
Can you elaborate? I'm not sure I follow you.
(I'll note anyway that (1) SQL functions can have s
Neil Conway wrote:
Mike Mascari wrote:
People who use views to achieve row security, which is a rather common
paradigm, cannot allow users to create functions with side effects.
Can you elaborate? I'm not sure I follow you.
(I'll note anyway that (1) SQL functions can have side effects: CREATE
F
Mike Mascari wrote:
People who use views to achieve row security, which is a rather common
paradigm, cannot allow users to create functions with side effects.
Can you elaborate? I'm not sure I follow you.
(I'll note anyway that (1) SQL functions can have side effects: CREATE
FUNCTION foo() RETURN
Neil Conway wrote:
Andrew Sullivan wrote:
This is not really analogous, because those are already on
Security (in the limited sense of "disabling features by default") is
not free; there is a tradeoff between security and convenience, security
and administrative simplicity, and so on. Given that
Andrew Sullivan wrote:
This is not really analogous, because those are already on
Which is my point: you're suggesting we retrofit a security policy onto
PG that does not apply to the vast majority of the base system -- and
that if applied would require fundamental changes.
Indeed. But that doe
Josh Berkus writes:
> Before we get into more minutia regarding potential security risk of plpgsql,
> are there any reasons *other* than security to not enable it?
Several potential issues have already been mentioned in this thread,
eg, what about shared library dependency vs linking plpgsql stat
People:
Before we get into more minutia regarding potential security risk of plpgsql,
are there any reasons *other* than security to not enable it?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 5: Have you che
On 2005-05-07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
>> Users can already define SQL functions by default, which certainly
>> provides "programmable features". I'm not quite sure what you mean by
>> "user exits."
>
>> I guess I'm missing how pl/pgsql is a f
Neil Conway <[EMAIL PROTECTED]> writes:
> Users can already define SQL functions by default, which certainly
> provides "programmable features". I'm not quite sure what you mean by
> "user exits."
> I guess I'm missing how pl/pgsql is a fundamentally greater security risk.
plpgsql has control s
On Sat, May 07, 2005 at 02:52:57PM +1000, Neil Conway wrote:
>
> So would you have us disable all the non-essential builtin functions?
> (Many of which have has security problems in the past.) What about the
> builtin encoding conversions, non-btree indexes, or a myriad of features
> that not a
Simon Riggs wrote:
I support Andrew's comment, though might reword it to
"Don't enable anything that gives users programmable features or user
exits by default".
Users can already define SQL functions by default, which certainly
provides "programmable features". I'm not quite sure what you mean b
On Sat, 2005-05-07 at 14:52 +1000, Neil Conway wrote:
> Andrew Sullivan wrote:
> > Sure it is. "Don't enable anything you don't need," is the first
> > security rule. Everything is turned off by default. If you want it,
> > enable it.
>
> So would you have us disable all the non-essential built
Andrew Sullivan wrote:
Sure it is. "Don't enable anything you don't need," is the first
security rule. Everything is turned off by default. If you want it,
enable it.
So would you have us disable all the non-essential builtin functions?
(Many of which have has security problems in the past.) Wh
Tom Lane wrote:
The denial of service risk in particular (whether intentional or
accidental) goes way up.
Does it really go "way up"? A malicious user who can execute SQL can DOS
the database trivially. Doing the (non-trivial) infrastructure work to
fix that is probably a good idea, but I don't s
I think that plpgsql should be maintained in core, enabled
by default with the ability to turn it off. This handles
the paranoid dba and security issue while giving the majority
of people what they already have by default. Of course
the dump create language statements will have to be dealt with
a
On Fri, May 06, 2005 at 03:37:21PM +1000, Neil Conway wrote:
>
> But I agree security is not a good argument against enabling it by default.
Sure it is. "Don't enable anything you don't need," is the first
security rule. Everything is turned off by default. If you want it,
enable it.
"Enabled
Tom Lane wrote:
Another problem with this proposal is that installations without
shared-library support will stop working entirely.
How do we manage to run regression tests for such installations?
I guess the philosphical question is "do we make the default the most
common case and provide e
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Another problem with this proposal is that installations without
>> shared-library support will stop working entirely.
> How do we manage to run regression tests for such installations?
We don't. However, degraded functionality is
Neil Conway <[EMAIL PROTECTED]> writes:
> But I agree security is not a good argument against enabling it by default.
Isn't it? Even without anything that we regard as a bug, availability
of a server-side programming language is still a risk factor from the
point of view of any reasonably paranoi
On Fri, 6 May 2005 04:45 pm, Jim C. Nasby wrote:
> On Fri, May 06, 2005 at 02:59:04PM +1000, Neil Conway wrote:
> > Is there a good reason that pl/pgsql is not installed in databases by
> > default?
>
> The only reason I've seen was "if we start with including plpgsql, where
> do we draw the line
On Fri, May 06, 2005 at 02:59:04PM +1000, Neil Conway wrote:
> Is there a good reason that pl/pgsql is not installed in databases by
> default?
The only reason I've seen was "if we start with including plpgsql, where
do we draw the line?" Personally, I think it should be installed by
default.
--
Josh Berkus wrote:
The only one I can think of is "security", which is pretty weak -- we've never
had a plpgsql security issue that I know of.
Well, no -- for instance,
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0245
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0247
But I agr
Neil,
> Is there a good reason that pl/pgsql is not installed in databases by
> default?
The only one I can think of is "security", which is pretty weak -- we've never
had a plpgsql security issue that I know of.
--
Josh Berkus
Aglio Database Solutions
San Francisco
--
Christopher Kings-Lynne wrote:
Problem is people restoring dumps that have the plpgsql create language,
etc. commands in them.
It should be possible to ignore those commands, and possibly issue a
warning. It's a bit ugly, but at least we can detect this situation
pretty unambiguously.
-Neil
---
Is there a good reason that pl/pgsql is not installed in databases by
default?
I think it should be. pl/pgsql is widely used, and having it installed
by default would be one less hurdle for newbies to overcome when
learning PostgreSQL. It would also make it easier to distribute
applications th
33 matches
Mail list logo
