Re: Possible major bug in PlPython (plus some other ideas)

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Kevin Jacobs <jacobs(at)penguin(dot)theopalgroup(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Possible major bug in PlPython (plus some other ideas)
Date: 2001-11-09 16:25:30
Message-ID: 3BEC037A.6ACE0DD2@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kevin Jacobs wrote:
>
> Hi everyone,
>
> I have noticed a possibly major issues in Plpython that may need to be
> addressed before 7.2 is released:
>
> 1) If Plpython is installed as a trusted language, and from what little I
> can glean from the documentation, it should not have any filesystem access.
> However, the default behavior of the restricted execution environment
> being used allows read-only filesystem access.

we have 'read-only filesystem access anyhow' :

pg72b2=# create table hack(row text);
CREATE
pg72b2=# copy hack from '/home/pg72b2/data/pg_hba.conf' DELIMITERS
'\01';
COPY
pg72b2=# select * from hack limit 10;

row
-------------------------------------------------------------------------------
#
# PostgreSQL HOST-BASED ACCESS (HBA) CONTROL FILE
#
#
# This file controls:
# o which hosts are allowed to connect
# o how users are authenticated on each host
# o databases accessible by each host
#
# It is read on postmaster startup and when the postmaster receives a
SIGHUP.
(10 rows)

do I can't consider having it in plputhon any bigger security threat.

using copy xxx to '/file/' we have even read-write access, we just can't
overwrite 0600 files. And you can do only what the postgres user can do.

> 2) I'm not sure why the TD dictionary exists. Why not create objects
> 'new', 'old' or 'event' in the global namespace when the interpreter is
> called in the appropriate contexts? The current way is unwieldy, not
> very 'Pythonic' (a frequent justification for change in the Python
> world), and not consistent with other PostgreSQL procedural backends.
> Its possible to keep TD for backward compatibility, so there is no
> downside.
>
> 3) 'old' and 'new' should also provide class-like syntax:
>
> e.g. old.foo, new.baz (using getitem)
>
> instead of
> old['foo'], new['baz'] (using getattr)
>
> Of course we cannot drop the getattr interface, since many valid column
> names are not valid python identifiers (I think -- I haven't looked at
> the SQL grammar lately, though I'm guessing that is the case).

You can have almost anything in an identifier if it is quoted.

-----------
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bradley McLean 2001-11-09 16:26:31 Re: Possible major bug in PlPython (plus some other ideas)
Previous Message Kevin Jacobs 2001-11-09 15:58:17 Re: Possible major bug in PlPython (plus some other ideas)