Re: modules - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: modules
Date
Msg-id 20080405002251.GC6497@yugib.highrise.ca
Whole thread Raw
In response to Re: modules  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: modules  ("D'Arcy J.M. Cain" <darcy@druid.net>)
Re: modules  (Andrew Dunstan <andrew@dunslane.net>)
Re: modules  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [080404 16:12]:
> And utterly, utterly insecure.
> 
> The fact that the referenced object file is a "trusted" Postgres module
> isn't enough to make it safe --- the user can still play hob with the
> system by creating functions with the wrong argument/result types,
> pointing at exported symbols that weren't meant to be callable
> functions, creating broken index opclasses from the functions, etc.

So those are all good reasons why we can't just assume a obj_file "safe"
to be used for a C language function with the current framework.  Would
a stronger "contract" mechanism between PG and symbols loaded from
object files used for functions...

Today was the first time I actually ever looked at the create function
and create language code, and I'm actually suprised at how little
"contract" there seems to be between a object file and the created
function.  But since it's always been guarded by super-user, it's
obviously not been an issue...

> I think you'd need to move the security gating up a level, and somehow
> see the SQL-language installation and deinstallation scripts as trusted.
> This goes back to the question of what is a module anyway.

And, unfortunately, I haven't seen any of those who have a thorough
enough knowledge and understanding of the whole system and security
issues talking a whole lot about that, well, beside shooting gaping
holes through lame ideas like mine ;-)

Maybe it's just because the problem really *is* that hard.  But I've
seen some pretty amazing features come in to PG over the past years, so
I know hard problems are solved by you guys...

Unfortunately, the current state really does seem to mean that the
"feature of modularity" really is the kiss of death, since things are
actively pushed out from core to be modular projects, making them
unusable for most people...

> Like Andrew, I'm a bit disturbed that people feel free to propose to
> implement this stuff when they evidently have read none of the prior
> discussions.

Well, I'm happy to go back to lurking for now...  Maybe after a few
years I'll have heard and seen more discussions and know better next
time ;-)

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Separate psql commands from arguments
Next
From: "D'Arcy J.M. Cain"
Date:
Subject: Re: modules