|
Hello Postgres Admin Mailing Group People – Our email admin says that we do not employ a “mail-back anti-spam system” and I hope that is true because I don’t want to cause you hassle. I manage many VMs running
Red Hat 9 at various levels from 9.2 through 9.5. On many of these VMs, I have followed instructions on the Postgres “Linux downloads (Red Hat family)” page:
https://www.postgresql.org/download/linux/redhat/ More specifically, according to the instructions for Version
15, Platform RHEL-9, and architecture x86_64, I ran the following commands: # Install the repository RPM:
sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm
# Disable the built-in PostgreSQL module:
sudo dnf -qy module disable postgresql I did not necessarily install any version of Postgres Server. On some of these VMs, I installed only the Postgres-12 client:
#
sudo dnf install postgresql12.x86_64 Installation of the Postgres Repository RPM causes the following file, shown here with the security context. I noticed that the security context user is system_u, different
from the security context user of the Red Hat repository: $
sudo ls -lZ /etc/yum.repos.d total 128 -rw-r--r--. 1 root root
system_u:object_r:system_conf_t:s0 13328 Apr 10 2024
pgdg-redhat-all.repo -rw-------. 1 root root
unconfined_u:object_r:system_conf_t:s0 111620 Jan 30 20:54 redhat.repo I have noticed that as soon as I introduce the Postgres repository, large batches of SELinux warnings start showing up in /var/log/messages
every 4 hours. These messages show up in batches of 32 every 4 hours. For example: [local_jeinhorn@itsdev ~]$
sudo grep setroubleshoot /var/log/messages | egrep "Feb 11 07:28:" | tail -6 Feb 11 07:28:22 itsdev setroubleshoot[159834]: SELinux is preventing /usr/bin/gpg from using the dac_override capability. For complete SELinux messages run:
sealert -l 78da067f-bff8-47fb-a13e-e5c398990ed4 Feb 11 07:28:22 itsdev setroubleshoot[159834]: SELinux is preventing /usr/bin/gpg from using the dac_override capability.#012#012***** Plugin dac_override
(91.4 confidence) suggests **********************#012#012If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system#012Then turn on full auditing to get path information about the offending file
and generate the error again.#012Do#012#012Turn on full auditing#012# auditctl -w /etc/shadow -p w#012Try to recreate AVC. Then execute#012# ausearch -m avc -ts recent#012If you see PATH record check ownership/permissions on file, and fix it,#012otherwise
report as a bugzilla.#012#012***** Plugin catchall (9.59 confidence) suggests **************************#012#012If you believe that gpg should have the dac_override capability by default.#012Then you should report this as a bug.#012You can generate a local
policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'gpg' --raw | audit2allow -M my-gpg#012# semodule -X 300 -i my-gpg.pp#012 Feb 11 07:28:22 itsdev setroubleshoot[159834]: SELinux is preventing /usr/bin/gpg from using the dac_override capability. For complete SELinux messages run:
sealert -l 78da067f-bff8-47fb-a13e-e5c398990ed4 Feb 11 07:28:22 itsdev setroubleshoot[159834]: SELinux is preventing /usr/bin/gpg from using the dac_override capability.#012#012***** Plugin dac_override
(91.4 confidence) suggests **********************#012#012If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system#012Then turn on full auditing to get path information about the offending file
and generate the error again.#012Do#012#012Turn on full auditing#012# auditctl -w /etc/shadow -p w#012Try to recreate AVC. Then execute#012# ausearch -m avc -ts recent#012If you see PATH record check ownership/permissions on file, and fix it,#012otherwise
report as a bugzilla.#012#012***** Plugin catchall (9.59 confidence) suggests **************************#012#012If you believe that gpg should have the dac_override capability by default.#012Then you should report this as a bug.#012You can generate a local
policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'gpg' --raw | audit2allow -M my-gpg#012# semodule -X 300 -i my-gpg.pp#012 Feb 11 07:28:32 itsdev systemd[1]: setroubleshootd.service: Deactivated successfully. Feb 11 07:28:32 itsdev systemd[1]: setroubleshootd.service: Consumed 1.016s CPU time. All the gpgkey file entries in are the same: [local_jeinhorn@useengatldevdb ~]$
sudo grep gpgkey /etc/yum.repos.d/pgdg-redhat-all.repo gpgkey=file:///etc/pki/rpm-gpg/PGDG-RPM-GPG-KEY-RHEL gpgkey=file:///etc/pki/rpm-gpg/PGDG-RPM-GPG-KEY-RHEL . . . <SNIP LOTS OF THE SAME> . . . gpgkey=file:///etc/pki/rpm-gpg/PGDG-RPM-GPG-KEY-RHEL gpgkey=file:///etc/pki/rpm-gpg/PGDG-RPM-GPG-KEY-RHEL The Postgres repository GPG key stored in
/etc/pki/rpm-gpg/PGDG-RPM-GPG-KEY-RHEL has already been imported into RPM: [local_jeinhorn@useengatldevdb ~]$
sudo tail -5 /etc/pki/rpm-gpg/PGDG-RPM-GPG-KEY-RHEL RfQX29x8baM4mdKVBmU9KQxRgno6lcks14STnawqf6o9nHxKp80VQrcNTsYHlq2B PGAanK8G4WeYojQWCQHBi73qCoTERMpBG73gpTIr836TBinGZaSZ8I1deUS89Hnw A62QO1TS57zxMTrstzaawLoCIHTqyJ2VeZrVC1INV4ENnyVsud3NaZtfWuIk7Q== =Elfg [local_jeinhorn@useengatldevdb ~]$
sudo rpm -qa gpg* gpgme-1.15.1-6.el9.x86_64 gpg-pubkey-fd431d51-4ae0493b gpg-pubkey-5a6340b3-6229229e gpg-pubkey-08b40d20-6581afc1 [local_jeinhorn@useengatldevdb ~]$
sudo rpm -qi
gpg-pubkey-08b40d20-6581afc1 Name : gpg-pubkey Version : 08b40d20 Release : 6581afc1 Architecture: (none) Install Date: Thu 29 Feb 2024 04:08:50 PM EST Group : Public Keys Size : 0 License : pubkey Signature : (none) Source RPM : (none) Build Date : Tue 19 Dec 2023 09:59:13 AM EST Build Host : localhost Packager : PostgreSQL RPM Repository <pgsql-pkg-yum@xxxxxxxxxxxxxxxxxxxx> Summary : PostgreSQL RPM Repository <pgsql-pkg-yum@xxxxxxxxxxxxxxxxxxxx> public key Description : -----BEGIN PGP PUBLIC KEY BLOCK----- Version: rpm-4.16.1.3 (NSS-3) mQGNBGWBr8EBDAC+atC3Hl2yKkFg0F4tDg4ABCTvvhgMn7g7oZ0vJqpaUAwUgijU +jLXH8qVSkyhk2eruSXlbj4dIMHhsbRQ1wUnd+tb8pZPdRaBFR9MzFMjvDzobAlZ . . . <SNIP> . . . PGAanK8G4WeYojQWCQHBi73qCoTERMpBG73gpTIr836TBinGZaSZ8I1deUS89Hnw A62QO1TS57zxMTrstzaawLoCIHTqyJ2VeZrVC1INV4ENnyVsud3NaZtfWuIk7Q== =Elfg -----END PGP PUBLIC KEY BLOCK----- The only way I was able to stop these messages was to update
/etc/dnf/dnf.conf and /etc/yum.repos.d/pgdg-redhat-all.repo and
disable the gpg checking in all instances (change
gpgcheck from 1 to 0 and change repo_gpgcheck from 1 to 0). I’m sure this is not the optimal way to avoid /var/log/messages getting spammed with setroubleshoot entries, but I don’t know what needs to be done! I am amazed this issue has
not been reported by others. Do you have advice on what I need to do, to stop the SELinux messages from getting logged into /var/log/messages? Many Thanks, Janet Einhorn System Administrator KNS FTW I.T. Infrastructure Team 215-784-6171 |
