From checkmk-werks-lvl1@lists.checkmk.com Wed May 29 15:27:03 2024 From: Checkmk werks level 1 To: checkmk-werks-lvl1@lists.checkmk.com Subject: [2.3.0] Checkmk Werk 15328 created: mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora Date: Wed, 29 May 2024 15:27:01 +0000 Message-ID: <1716996421.058157.15308.nullmailer@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4889739703606152277==" --===============4889739703606152277== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable [//]: # (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. 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. --===============4889739703606152277==--