From checkmk-werks-lvl1@lists.checkmk.com Thu Apr 18 12:58:10 2024 From: Checkmk werks level 1 To: checkmk-werks-lvl1@lists.checkmk.com Subject: [2.1.0] Checkmk Werk 15328 created: mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora Date: Thu, 18 Apr 2024 12:58:08 +0000 Message-ID: <1713445088.948528.1054.nullmailer@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4436915838948735009==" --===============4436915838948735009== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Title: mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora Class: fix Compatible: incomp Component: checks Date: 1712309908 Edition: cre Level: 1 Version: 2.1.0p42 You are affected by this Werk if you use mk_oracle agent plugin on unix. mk_oracle only works if it can find a sqlnet.ora in your $TNS_ADMIN folder. In the past, mk_oracle executed all orac= le binaries as root, so sqlnet.ora was alwas readable. With Werk #16232 the oracle binaries a= re executed with a low privileged user, so it might be the case, that sqlnet.ora can not be read by this user. mk_oracle will exit early if it can not read sqlnet.ora. The error message might look like: /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 fil= e. The error message will also be visible in the oracle_instance check. If you use the agent bakery to roll out mk_oracle to unix servers using .rpm, .deb or Solaris .pkg packages, you have to u= se the 'sqlnet.ora permission group' bakery rule to adapt the group of the sqlnet.ora 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 tgz package, you will have to manually adjust the permissions of the sqlnet.ora file. --===============4436915838948735009==--