We have a web service written in java (using Axis 1.4). We access this in c++ code using gSOAP (2.8.101). We are using OpenSSL (1.1.1e). On RHEL 8 we are seeing the SOAP 1.2 fault. The error is as below: SOAP 1.2 fault: SOAP-ENV:Receiver [no subcode] "Permission denied" Detail: connect failed in tcp_connect()
The same code works good in RHEL7. Any suggestions on how to fix this?
It seems as if SELinux is blocking the connection. To temporarily allow the connection, you can use setenforce 0. This won't survive a server reboot, so if you'd like it to survive, you need to set SELinux to work in permissive mode in /etc/selinux/config.
To continue working in enforcing mode, depending on the application, there might be a built-in SELinux policy to allow the connection you need with SELinux set to enforcing just by enabling an appropriate boolean. You can get the list of all SELinux booleans by executing:
getsebool -a # List all available SELinux booleans on your system
For example, to allow the HTTPD scripts and modules to connect to the network, enable the following SELinux boolean:
sudo setsebool -P httpd_can_network_connect on
If you don't want to allow HTTPD to connect to any port, you can use an appropriate boolean:
sudo setsebool -P httpd_can_network_connect_db on
This will allow HTTPD to connect to the database over the network. If there's no appropriate boolean for you to enable, you'll have to build your own policy. You can do that using the audit2allow -M command. For example, if your command that generates an error in your audit.log is httpd, you can do the following:
sudo ausearch -c 'httpd' --raw | audit2allow -M my-policy
sudo semodule -X 300 -i my-policy.pp
Usually, it's not a good practice to use audit2allow to allow access for a service if there's a built-in boolean available for that service. Use audit2allow as your last resort if there is no appropriate boolean for your paticular service.