On Thu, 2004-12-02 at 02:21 -0500, Greg Stark wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>
> > John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted
> > code.
>
> You know, there's something twisted in postgres's naming scheme here. How is
> it that "trusted" langu
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted
> code.
You know, there's something twisted in postgres's naming scheme here. How is
it that "trusted" languages the ones that need a sandbox? and "untrusted"
languages the o
Bruce Momjian said:
>
> Uh, what was the TODO here? I forgot.
>
>
John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted
code. If there's a TODO it would be to investigate the possibility, as I am
very far from certain that there is a simple way to do it safely right now.
Maybe
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Uh, what was the TODO here? I forgot.
I think we already did what we decided was safe there.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Uh, what was the TODO here? I forgot.
---
John Hansen wrote:
> > I think it is *way* too late in the dev cycle to be proposing this.
> > Maybe it should be a TODO item - I at least don't have time even to
> > think about
> I think it is *way* too late in the dev cycle to be proposing this.
> Maybe it should be a TODO item - I at least don't have time even to
> think about the implications os using these pragmas. The effect of the
> first is achievable via an environment setting, I believe.
>
> If you need these
John Hansen wrote:
Applied, with changes to allow srand and disallow sprintf, as per
subsequent discussion.
How about allowing:
use utf8;
use locale;
?
I think it is *way* too late in the dev cycle to be proposing this.
Maybe it should be a TODO item - I at least don't have time even to
> Applied, with changes to allow srand and disallow sprintf, as per
> subsequent discussion.
How about allowing:
use utf8;
use locale;
?
Kind Regards,
John
---(end of broadcast)---
TIP 6: Have you searched our list archives?
ht
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> It has just been brought to my attention that we are being very
> restrictive about what we allow to be done in trusted plperl.
> ...
> OK, based on this and some further thought, I have prepared the attached
> patch which does the right thing, I thin
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
--
> >Andrew Dunstan wrote:
> >
> >
> >>...
> >>
> >>The patch also does some other inconsequential tidying of overlong
> >>lines, and removes some unnecessary ops in the unsafe case. These are
> >>basically cosmetic - the only significant part is replacing this:
> >>
> >>$PLContainer->permit(
Andrew, can you or someone summarize were we left this issue and your
patch?
---
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >
> >
> >>The question in my mind is "What a
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
An
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The question in my mind is "What are we protecting against?" ISTM it is
the use of the pl as a vector to attack the machine and postgres. Does a
segfault come into that category? After all, isn't it one of postgres's
strengths that w
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The question in my mind is "What are we protecting against?" ISTM it is
> the use of the pl as a vector to attack the machine and postgres. Does a
> segfault come into that category? After all, isn't it one of postgres's
> strengths that we can surviv
Tom Lane wrote:
David Helgason <[EMAIL PROTECTED]> writes:
A postgres question I don't know the answer to is whether allowing the
user to trigger a segfault is a security problem.
It would not be cool for a trusted language to allow such things, that's
for sure.
You could debate back and
David Helgason wrote:
On 14. okt 2004, at 21:09, Andrew Dunstan wrote:
It has just been brought to my attention that we are being very
restrictive about what we allow to be done in trusted plperl.
Basically we allow the :default and :base_math set of operations (run
perldoc Opcode or see
http:
David Helgason <[EMAIL PROTECTED]> writes:
> A postgres question I don't know the answer to is whether allowing the
> user to trigger a segfault is a security problem.
It would not be cool for a trusted language to allow such things, that's
for sure.
You could debate back and forth about whether
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> You can now - it's part of :base_math. What we should do, however, is
> disallow is calling srand, since pg goes to quite a bit of trouble to
> seed the PRNG.
But changing the PRNG seed within one backend is not a security issue.
At least, we allow an
On Thu, 14 Oct 2004, Andrew Dunstan wrote:
> >That makes sense. Allowing "rand" would be nice too.
>
> You can now - it's part of :base_math.
Oh, ok. I saw it's not included in :base_core despite being in :base_math,
but didn't realize explicitly including :base_math would bring it back.
> Wha
On 14. okt 2004, at 21:09, Andrew Dunstan wrote:
It has just been brought to my attention that we are being very
restrictive about what we allow to be done in trusted plperl.
Basically we allow the :default and :base_math set of operations (run
perldoc Opcode or see http://www.perldoc.com/perl5.
Jon Jensen wrote:
On Thu, 14 Oct 2004, Andrew Dunstan wrote:
It has just been brought to my attention that we are being very
restrictive about what we allow to be done in trusted plperl. Basically
we allow the :default and :base_math set of operations (run perldoc
Opcode or see http://www.pe
On Thu, 14 Oct 2004, Andrew Dunstan wrote:
> It has just been brought to my attention that we are being very
> restrictive about what we allow to be done in trusted plperl. Basically
> we allow the :default and :base_math set of operations (run perldoc
> Opcode or see http://www.perldoc.com/per
It has just been brought to my attention that we are being very
restrictive about what we allow to be done in trusted plperl. Basically
we allow the :default and :base_math set of operations (run perldoc
Opcode or see http://www.perldoc.com/perl5.8.0/lib/Opcode.html for
details of what these me
24 matches
Mail list logo
