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

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
authenticatedon each host#      o databases accessible by each host# # It is read on postmaster startup and when the
postmasterreceives 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