Обсуждение: plperl _init settings
There appears to be some significant misunderstanding of what can be done effectively using the various *_init settings for plperl. In particular, some people have got an expectation that modules loaded in plperl.on_init will thereby be available for use in trusted plperl. I propose to add the following note to the docs: Preloading modules using plperl.on_init does not make them available for use by plperl. External perl modules can onlybe used in plperlu. Comments? cheers andrew
On Mar 2, 2010, at 4:33 PM, Andrew Dunstan wrote: > I propose to add the following note to the docs: > > Preloading modules using plperl.on_init does not make them available > for use by plperl. External perl modules can only be used in plperlu. Perhaps add a note that some other interface to allow preloaded modules to also be available to plperl may be provided inthe future. Best, David
David E. Wheeler wrote: > On Mar 2, 2010, at 4:33 PM, Andrew Dunstan wrote: > > >> I propose to add the following note to the docs: >> >> Preloading modules using plperl.on_init does not make them available >> for use by plperl. External perl modules can only be used in plperlu. >> > > Perhaps add a note that some other interface to allow preloaded modules to also be available to plperl may be providedin the future. > > > No, that's far from a done deal. cheers andrew
On Mar 2, 2010, at 6:00 PM, Andrew Dunstan wrote: >> Perhaps add a note that some other interface to allow preloaded modules to also be available to plperl may be providedin the future. > > No, that's far from a done deal. Hence the “may.” But either way. David
On Tue, Mar 02, 2010 at 07:33:47PM -0500, Andrew Dunstan wrote: > > There appears to be some significant misunderstanding of what can be > done effectively using the various *_init settings for plperl. > > In particular, some people have got an expectation that modules > loaded in plperl.on_init will thereby be available for use in > trusted plperl. > > I propose to add the following note to the docs: > > Preloading modules using plperl.on_init does not make them available > for use by plperl. External perl modules can only be used in plperlu. > > Comments? Sounds good. FYI the maintainers of Safe are aware of (at least) two exploits which are being considered at the moment. You might want to soften the wording in http://developer.postgresql.org/pgdocs/postgres/plperl-trusted.html "There is no way to ..." is a stronger statement than can be justified. The docs for Safe http://search.cpan.org/~rgarcia/Safe-2.23/Safe.pm#WARNING say "The authors make no warranty, implied or otherwise, about the suitability of this software for safety or security purposes". Tim.
Tim Bunce wrote: > FYI the maintainers of Safe are aware of (at least) two exploits which > are being considered at the moment. > > You might want to soften the wording in > http://developer.postgresql.org/pgdocs/postgres/plperl-trusted.html > "There is no way to ..." is a stronger statement than can be justified. > Perhaps "There is no way provided to ...". > The docs for Safe http://search.cpan.org/~rgarcia/Safe-2.23/Safe.pm#WARNING > say "The authors make no warranty, implied or otherwise, about the > suitability of this software for safety or security purposes". > > > Well, we could put in similar weasel words I guess. But after all, Safe's very purpose is to provide a restricted execution environment, no? cheers andrew
On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote: > > > > Well, we could put in similar weasel words I guess. But after all, > Safe's very purpose is to provide a restricted execution environment, no? We already do, in our license. Joshua D. Drake > > cheers > > andrew > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote: > > > > Well, we could put in similar weasel words I guess. But after all, > Safe's very purpose is to provide a restricted execution environment, no? We already do, in our license. Joshua D. Drake > > cheers > > andrew > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
Joshua D. Drake wrote: > On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote: > > >>> >>> >> Well, we could put in similar weasel words I guess. But after all, >> Safe's very purpose is to provide a restricted execution environment, no? >> > > We already do, in our license. > > > True. I think the weasel formula I prefer here is a bit different. It might be reasonable to say something along the lines of: To the extent it is prevented by the Perl Safe module, there is no way provided to access internals of the databaseserver process or to gain OS-level access with the permissions of the server process, as a C function can do. cheers andrew
On Wed, Mar 03, 2010 at 07:01:56PM -0500, Andrew Dunstan wrote: > Joshua D. Drake wrote: > >On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote: > > > >>Well, we could put in similar weasel words I guess. But after > >>all, Safe's very purpose is to provide a restricted execution > >>environment, no? > > > >We already do, in our license. > > True. I think the weasel formula I prefer here is a bit different. > It might be reasonable to say something along the lines of: > > To the extent it is prevented by the Perl Safe module, there is no > way provided to access internals of the database server process or > to gain OS-level access with the permissions of the server process, > as a C function can do. Here's a patch that: 1. adds wording like that to the docs. 2. randomises the container package name (a simple and sound security measure). 3. requires Safe 2.25 (which has assorted fixes, including security). 4. removed a harmless but suprious exclamation mark from the source. Tim.
Вложения
Tim Bunce <Tim.Bunce@pobox.com> writes:
> Here's a patch that:
> 1. adds wording like that to the docs.
> 2. randomises the container package name (a simple and sound security measure).
> 3. requires Safe 2.25 (which has assorted fixes, including security).
> 4. removed a harmless but suprious exclamation mark from the source.
#3 is still an absolute nonstarter, especially for a patch that we'd
wish to backpatch.
regards, tom lane
On Mar 8, 2010, at 8:03 AM, Tom Lane wrote: > #3 is still an absolute nonstarter, especially for a patch that we'd > wish to backpatch. You're at least going to want to exclude Safe 2.20 - 2.23, IIUC. Best, David
"David E. Wheeler" <david@kineticode.com> writes:
> On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
>> #3 is still an absolute nonstarter, especially for a patch that we'd
>> wish to backpatch.
> You're at least going to want to exclude Safe 2.20 - 2.23, IIUC.
If those aren't versions that are likely to be in wide use, no objection
to that. I'm just concerned about arbitrarily breaking existing
installations. I note that Fedora 11 and OS X 10.6.2 are providing Safe
2.12, which means the proposed patch would break plperl on every machine
I have, without easy recourse --- I am not likely to install a private
version of Safe under either OS, and I doubt many other PG users would
wish to either. The net effect would be to prevent PG users from
upgrading until the OS vendors get around to issuing new versions,
which is not helpful. Particularly if the vendor chooses to back-patch
Safe security fixes without bumping the visible version number, as is
not unlikely for Red Hat in particular.
regards, tom lane
On Mon, Mar 08, 2010 at 11:03:27AM -0500, Tom Lane wrote: > Tim Bunce <Tim.Bunce@pobox.com> writes: > > Here's a patch that: > > 1. adds wording like that to the docs. > > 2. randomises the container package name (a simple and sound security measure). > > 3. requires Safe 2.25 (which has assorted fixes, including security). > > 4. removed a harmless but suprious exclamation mark from the source. > > #3 is still an absolute nonstarter, especially for a patch that we'd > wish to backpatch. This is a patch for 9.0. Backpatching is a separate issue. I think Safe 2.25 should be required, but I'll let whoever applies the patch tweak/delete that hunk as desired. Tim.
On Mar 8, 2010, at 9:14 AM, Tom Lane wrote: > If those aren't versions that are likely to be in wide use, no objection > to that. Yes, those are a series of releases in the last couple of months that had one level of brokenness or another I'm going totest 2.25 today. > I'm just concerned about arbitrarily breaking existing > installations. I note that Fedora 11 and OS X 10.6.2 are providing Safe > 2.12, which means the proposed patch would break plperl on every machine > I have, without easy recourse --- I am not likely to install a private > version of Safe under either OS, and I doubt many other PG users would > wish to either. The net effect would be to prevent PG users from > upgrading until the OS vendors get around to issuing new versions, > which is not helpful. Agreed, older ones should be allowed; the Perl community should recommend that everyone upgrade to get improved security,but it shouldn't be required. > Particularly if the vendor chooses to back-patch > Safe security fixes without bumping the visible version number, as is > not unlikely for Red Hat in particular. This is why I hate packaging systems. Frankly, Red Hat's Perl has been consistently broken for close to a decade, mainlybecause of patching practices such as this. Best, David
2010/3/8 David E. Wheeler <david@kineticode.com>: >> Particularly if the vendor chooses to back-patch >> Safe security fixes without bumping the visible version number, as is >> not unlikely for Red Hat in particular. > > This is why I hate packaging systems. Frankly, Red Hat's Perl has been consistently broken for close to a decade, mainlybecause of patching practices such as this. Goes both way - it's the main reason I hate CPAN, and I know many sysadmins who hold just that position. (to be clear: the lack of back-branch management on CPAN is what sucks) But we're not arguing that. We know it's a situation out there, and we jus thave to deal with it. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Mon, Mar 8, 2010 at 09:03, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Tim Bunce <Tim.Bunce@pobox.com> writes: >> 3. requires Safe 2.25 (which has assorted fixes, including security). > #3 is still an absolute nonstarter, especially for a patch that we'd > wish to backpatch. FWIW I think its a given you probably always want the latest version of X or Y. I mean what happens when Safe 2.26 comes out and fixes more issues? We blacklist 2.25? Seems like a PITA. Why not just have something in the docs about keeping your stuff up2date? That being said I would be in favor of at least saying "Hey! your using a known broken version of Safe". Maybe something like the below at pl_perl init time? (That is instead of requiring >v2.25 just complain about older versions) elog(WARNING, "Safe versions before 2.25 have known issues. Please consider upgrading."); Thoughts?
Alex Hunsaker <badalex@gmail.com> writes:
> That being said I would be in favor of at least saying "Hey! your
> using a known broken version of Safe". Maybe something like the below
> at pl_perl init time? (That is instead of requiring >v2.25 just
> complain about older versions)
> elog(WARNING, "Safe versions before 2.25 have known issues. Please
> consider upgrading.");
We're in the service of providing a tool, not a nanny.
regards, tom lane
On Mon, Mar 8, 2010 at 10:14, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "David E. Wheeler" <david@kineticode.com> writes: >> On Mar 8, 2010, at 8:03 AM, Tom Lane wrote: >>> #3 is still an absolute nonstarter, especially for a patch that we'd >>> wish to backpatch. > >> You're at least going to want to exclude Safe 2.20 - 2.23, IIUC. > > If those aren't versions that are likely to be in wide use, no objection > to that. I'm just concerned about arbitrarily breaking existing > installations. Here are a few version numbers for released perls: perl | safe version 5.8.8 | 2.12 5.8.9 | 2.16 5.10.0 | 2.12 5.10.1 | 2.18 5.12 looks like it will release with > 2.25, 5.10.2 if it ever gets released is currently at 2.18, 5.8.10 does not even seem to be on the horizon. So unless you installed a private version or your distro is providing updates (I looked at: arch, debian, fedora and openbsd. And they don't seem to.) it seems unlikely to see >2.18 in the wild.