Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: [HACKERS] plperl Safe restrictions

0 views
Skip to first unread message

Bruce Momjian

unread,
Nov 11, 2004, 12:33:48 PM11/11/04
to
> >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(':base_math');
> >>
> >>with this:
> >>
> >> $PLContainer->permit(qw[:base_math !:base_io !srand sort sprintf time]);
> >>
> >>
> >>
> >
>
> As per previous discussions, please remove "!srand" and "sprintf"
> if/when applying.

OK.

--
Bruce Momjian | http://candle.pha.pa.us
pg...@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane

unread,
Nov 16, 2004, 5:06:15 PM11/16/04
to
Andrew Dunstan <and...@dunslane.net> 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 think, both in terms of what we
> allow and what we don't.

Applied, with changes to allow srand and disallow sprintf, as per
subsequent discussion.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majo...@postgresql.org

John Hansen

unread,
Nov 16, 2004, 6:46:21 PM11/16/04
to
> 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 badly enough, use plperlu where there are no
> restrictions to overcome - the big problem is that 'use anything'
> requires that we enable the 'require' op, and that is certainly not
> going to happen without a great deal of thought.

Fair enough, was just a suggestion as they seem obviously useful, even
to the non-superuser plperl programmer.

TODO item would suffice :)

... John

0 new messages