PierreVn
PierreVn

Reputation: 25

How to configure Oracle 11g to launch sqlplus?

On a RedHat 6 server, a third party application requires to be root to run and needs access to sqlplus. I have a running database, I can run sqlplus as user 'oracle'. When logged in as user root, 'sqlplus usr/pwd@dbname' works as expected. The trouble is that this agent needs to run sqlplus with no parameters and it always returns ORA-12546: TNS:permission denied.

I've read a dozen times that enabling root to launch Oracle is a security issue but I really have no other choice.

Running Oracle 11.2.0.1.0.

Any help will be much appreciated as I've googled for 2 days with no success.

Upvotes: 1

Views: 7534

Answers (1)

Alex Poole
Alex Poole

Reputation: 191235

From the documentation, ORA_12546 is:

ORA-12546: TNS:permission denied
Cause: User has insufficient privileges to perform the requested operation. Action: Acquire necessary privileges and try again.

Which isn't entirely helpful, but various forum and blog posts (way too many to link to, Googling for the error shows a lot of similar advice) mention permissions on a particular part of the installation, $ORACLE_HOME/bin/oracle, which is a crucial and central part of most of the services.

Normally the permissions on that file would be -rws-r-s--x, with the file owned by oracle:dba, and this error can occur when the word-writable flag - the final x in that pattern - is not set. Anyone in the dba group will still be able to execute it, but those outside will not.

Your listener seems to be fine as you can connect remotely, by specifying @dbname in the connect string. The listener runs as oracle (usually, could be grid with HA, RAC or ASM) so it is in the dba group and can happily hand-off connections to an instance of the oracle executable.

When you connect without going via the listener, you have to be able to execute that file yourself. It appears that root cannot execute it (or possibly some other file, but this is usually the culprit, apparently), which implies the world-writable bit is indeed not set.

As far as I can see you have three options:

  • set the world-writable bit, with chmod o+x $ORACLE_HOME/bin/oracle; but that opens up the permissions for everyone, and presumably they've been restricted for a reason;
  • add root to the dba group, via usermod or in the /etc/group; which potentially weakens security as well;
  • use SQL*Net even when you don't specify @dbname in the connect string, by adding export TWO_TASK=dbname to the root environment.

You said you don't have this problem on another server, and that the file permissions are the same; in which case root might be in the dba group on that box. But I think the third option seems the simplest and safest. There is a fourth option I suppose, to install a separate instant client, but you'd have to set TWO_TASK anyway and go over SQL*Net, and you've already ruled that out.

I won't dwell on whether it's a good idea to run sqlplus (or indeed the application that needs it) as root, but will just mention that you'd could potentially have a script or function called sqlplus that switches to a less privileged account via su to run the real executable, and that might be transparent to the application. Unless you switch to the oracle account though, which is also not a good idea, you'd have the same permission issue and options.

Upvotes: 1

Related Questions