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 early
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
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
Mike Mascari mascarm@mascari.com 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
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 where
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
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 builtin
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 by
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 all
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 structures
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 fundamentally
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
Josh Berkus josh@agliodbs.com 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
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
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 I
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()
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
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
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
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
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.
--
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?
Well,
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 paranoid
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 better
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
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
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.)
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
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
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
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
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
32 matches
Mail list logo
