RE: is it ok to tighten up extproc security?

From: Newman, Christopher <>
Date: Fri, 14 Nov 2008 08:22:32 -0600
Message-ID: <>

In addition, I believe the extproc stanza is created by default in the listener.ora, so it's possible no one specifically set it up.

  • Chris

From: [] On Behalf Of Andrew Kerber Sent: Friday, November 14, 2008 8:19 AM
Subject: Re: is it ok to tighten up extproc security?

That is a standard Sox recommendation. I would go ahead and get rid of it, I most applications do not use the extproc. On Fri, Nov 14, 2008 at 1:51 AM, Douglas Cowles <> wrote:

An application called appdetective has flagged one of my systems as having an extproc service which is a security violation in it's estimation. It recommend I either remove the lines from listener.ora to prevent the service from spawning or modify the protocol.ora to use validnode checking parameter to only accept requests from certain network addresses.  

My first question is how can I determine whether there are any external procs being used in the database in the first place.   I would figure it would require a library, but all the libraries I have in the database are owned by sys and don't seem user generated even for Peoplesoft purposes.   I would imagine I could turn this off but someone must have modified the listener at some point to allow extproc in the first place which makes me think someone wanted to do it but when and for what.  It could have been set up 3 years ago.  

Secondly, if the first question is not definitive, is simply putting the database server itself as the only node allowed to invoke extproc a solution that is likely to handle things?  It is possible a Peoplesoft app or web server would want to invoke an extproc on a database server?

This is a database on AIX 5.3 running Peoplesoft  9 (unsure of exact version)

Any other thoughts about how to handle a violation item like this would be appreciated.

Doug Cowles

Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'
Received on Fri Nov 14 2008 - 08:22:32 CST

Original text of this message