Implications of chmod o+r on Oracle *msb files

[Ralph Grothe]

Hi,

I know there are lots of Oracle knowledgable guys in this forum.
So I start this thread although it isn't strictly an HP-UX issue.
On the contrary, it is more related to how Oracle files got installed on Linux RHES.

I run various Nagios checks on this host.
As there is also an Oracle 10 something instance running I wish to make use of the simple but elegant check_oracle plugin, which comes with the standard set of Nagios plugins.
Since the plugins get remotely executed via the nrpe started service by xinetd,
these plugins get executed under some underprivileged uid.

When I run check_oracle under the uid that xinetd spawns nrpe with I get this nasty error:

$ ORACLE_HOME=/oracle/SOME_SID/102_64 /usr/lib64/nagios/plugins/check_oracle --login SOME_SID
Error 6 initializing SQL*Plus
Message file sp1.msb not found
SP2-0750: You may need to set ORACLE_HOME to your Oracle software directory
CRITICAL -

As root I did a find $ORACLE_HOME -type f -name \*msb,
and I found loads of, what appears to me to simply be Oracle messages keeping, *msb file
which had no perms set for others.

Of course could I set up some sudoers rule to execute the check_oracle or sqlplus command as oracle.
But this seems too much fuss for the purpose of this very nrpe check, which would unnecessarily set it apart from all the other nrpe run checks.
So the simplest solution for me would be to run as root something like
# find $ORACLE_HOME -type f -name \*msb -exec chmod o+r {} \;

I cannot see what secret information could be stored in the *msb files, other than some silly version information or error messages of various Oracle commands in all kinds of languages, to feel too reluctant to execute the above find.

However, since I'm no Oracle DBA, I'm not sure if I would bugger up something by doing so.

Could you advise?

Ralph

[Ralph Grothe]

Phew, after I inspected the syscall trace through "strace -e trace=file" of this check_oracle I got struck by bunches of ENOENT or EACCESS errors on various stat calls.
To fix this would have meant to chmod almost any Oracle installation file as it looked.
So I resorted to sudo.
In sudoers I added an apropiate rule,
and now the check works when run remotely from my Nagios server:


$ check_nrpe -H ora_host -c check_ora_login
OK - dummy login connected
$ echo $?
0


Sorry, for bothering you.

[Yogeeraj_1]

hi Ralph,

By default all new Oracle Database Software installation s, have "no perms set for others".

For Application Server software, it has been stated that: "For security reasons, a decision was taken, by OracleAS / Oracle Developer Suite product development, to make 700 the default permissions (for the majority of binaries in the technology stack). This was also implemented by CPU patches." --- see metalink note 336492.1.

I believe that it is safe to selectively modify the privileges of the files.

If you are still not sure whether you should make the change, i would suggest that you contact Oracle Support for more advice.

kind regards
yogeeraj

[Steven E. Protter]

Shalom,

There should be a oracle user to start the database server. This user must own all databaase and configuration filese for normal operation.

I don't recommend changing ownership on a running Oracle database. I'm not a DBA either but I've been working with Oracle since 1998.

SEP

[Ralph Grothe]

Hello guys,

as already stated, I found a solution by the sudo kludge.
This works perfectly well for my oracle check.
You are right, one shouldn't tinker with the permissions of the oracle installation.
As Yogeeraj cited, the Oracle folks had surely restricted access for good reasons.
I wouldn't call Oracle Support, even if I was entitled to (as said, I'm not the DBA of the instances).
I am sure they only would frown and ask silly questions like, why I would want to monitor their product with some arcane and rinkydink tool like Nagios instead of using their fully supported super-duper suite of tools.

[Steven E. Protter]

Ralph,

I think its perfectly acceptable to monitor oracle. If you choose Nagios, thats great.

There are two methods we generally use for Oracle monitoring.

1) Check the process, a variation on ps -ef | grep . The problem with that is the database can freeze and the monitor would never know.

2) A simple scripted sqlplus script that reads dual or some system table. This is a good monitor, though its harder to write and must be shut off prior to a database shutdown.

SEP