[//]: # (werk v2)
# mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora
key | value
---------- | ---
compatible | no
version | 2.3.0b6
date | 2024-04-05T09:38:28+00:00
level | 1
class | fix
component | checks
edition | cre
You are affected by this Werk if you use mk_oracle agent plugin on unix.
<tt>mk_oracle</tt> only works if it can find a <tt>sqlnet.ora</tt>
in your
<tt>$TNS_ADMIN</tt> folder. In the past, <tt>mk_oracle</tt>
executed all oracle
binaries as root, so <tt>sqlnet.ora</tt> was alwas readable. With <a
href="https://checkmk.com/werk/16232">Werk #16232</a> the oracle
binaries are
executed with a low privileged user, so it might be the case, that
<tt>sqlnet.ora</tt> can not be read by this user.
<tt>mk_oracle</tt> will exit early if it can not read
<tt>sqlnet.ora</tt>. The
error message might look like:
<code>
/etc/check_mk/sqlnet.ora can not be read by user "oracle"! Either use
'sqlnet.ora permission group' bakery rule, or directly modify permissions of the
file.
</code>
The error message will also be visible in the <tt>oracle_instance</tt> check.
If you use the agent bakery to roll out mk_oracle to unix servers using
<tt>.rpm</tt>, <tt>.deb</tt> or Solaris <tt>.pkg</tt>
packages, you have to use
the 'sqlnet.ora permission group' bakery rule to adapt the group of the
<tt>sqlnet.ora</tt> file, otherwise your permission changes might be
overwritten by updating the agent.
Otherwise it is sufficient to adapt the permissions.
If you install the agent on Unix using the <tt>tgz</tt> package, you will
have
to manually adjust the permissions of the <tt>sqlnet.ora</tt> file.