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
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) |