如何配置Oracle 11g以启动sqlplus? [英] How to configure Oracle 11g to launch sqlplus?

问题描述

在RedHat 6服务器上，第三方应用程序需要是root用户才能运行，并且需要访问sqlplus.我有一个正在运行的数据库，我可以以用户"oracle"的身份运行sqlplus.当以root用户身份登录时，"sqlplus usr/pwd @ dbname"可以按预期工作.问题在于该代理程序需要运行不带任何参数的sqlplus，并且始终返回ORA-12546:TNS:权限被拒绝.

我已经读过十几遍了，让root用户启动Oracle是一个安全问题，但是我真的别无选择.

运行Oracle 11.2.0.1.0.

通过Google搜索2天没有成功，任何帮助将不胜感激.

解决方案

根据文档，ORA_12546为:

ORA-12546:TNS:权限被拒绝
原因:用户没有足够的特权来执行请求的操作. 操作:获取必要的权限，然后重试.

这并不是完全有帮助，但是各种论坛和博客文章(链接太多，搜索错误显示了很多类似的建议)提到了安装的特定部分$ORACLE_HOME/bin/oracle的权限，是大多数服务中至关重要的核心部分.

通常该文件的权限为-rws-r-s--x，该文件由oracle:dba拥有，并且当未设置可写单词标志(该模式中的最后一个x)时，会发生此错误. dba组中的任何人仍然可以执行它，但是外面的人则不能.

您的监听器似乎很好，因为您可以通过在连接字符串中指定@dbname进行远程连接.侦听器以oracle身份运行(通常可以是具有HA，RAC或ASM的grid)，因此它位于dba组中，可以愉快地将连接移交给oracle可执行文件的实例.

在不通过侦听器进行连接的情况下，您必须能够自己执行该文件.看来root无法执行它(或者可能是其他文件，但是显然这通常是罪魁祸首)，这意味着确实没有设置可写世界的位.

据我所知，您有三个选择:

• 用chmod o+x $ORACLE_HOME/bin/oracle设置世界可写位；但这会向所有人开放权限，大概是出于某种原因限制了权限；
• 通过usermod或/etc/group将root添加到dba组中；这也可能削弱安全性；
通过在root环境中添加export TWO_TASK=dbname，即使未在连接字符串中指定@dbname时，也可​​以使用SQL * Net.

您说您在另一台服务器上没有此问题，并且文件许可权是相同的；在这种情况下，root可能在该框的dba组中.但是我认为第三种选择似乎是最简单，最安全的.我想有第四个选择，安装一个单独的即时客户端，但是您仍然必须设置TWO_TASK并通过SQL * Net，并且您已经排除了这一点.

我不会讨论将sqlplus(或者实际上需要它的应用程序)作为root运行是否是一个好主意，但只会提到您可能拥有一个名为<的脚本或函数. c22>通过su切换到特权较低的帐户以运行实际的可执行文件，并且对应用程序可能是透明的.除非您切换到oracle帐户(这也不是一个好主意)，否则您将拥有相同的权限问题和选项.

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.

解决方案

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.

这篇关于如何配置Oracle 11g以启动sqlplus?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！