Support Ticket Using Sendmail, Not Working

First of all, thank you for this wonderful app. We’ve deployed it less than 2 months ago, and we’re already seeing an uptick in resource usage at our HPC Center.

We’re trying to get the built-in Support Ticket from the Help menu working, and we’re running OOD version 3.01 on a RHEL 8 server. Our postfix daemon is up, and can successfully use the sendmail command with the -i and -f options:

Note that the second sendmail test from the image above does fail, and it shows in the logs:

However, when we test the support ticket form accessible from the Help dropdown menu, nothing gets logged in the maillog and we get this error message in the browser instead:

Here is our support_ticket.yml file:
support_ticket.yml.txt (1.1 KB)

Any assistance that you can offer is appreciated.

I think in Linux 126 means it’s not executable. When you tested in shell session you need 2 things - (1) to be an unprivileged user (i.e., not root) and (2) to conduct the test on the the server that OOD is running.

[~()]  touch foo
[~()]  ./foo
-bash: ./foo: Permission denied
[~()]  echo $?

Both of these conditions were fulfilled while we were testing. We are STIG compliant and we do have many directories mounted with the noexec option. Does this app create and execute any temporary scripts?
Here’s our /etc/fstab file in case you need it.
fstab.txt (2.0 KB)

I don’t believe so, at this point we’re deep in the ruby libraries - but it appears to be just issuing a single command.

Maybe get rid of that configuration to use sendmail and just use the default local SMTP server?

You were right, it was a permission issue. We have SELinux in enforcing mode with confined users. Once we turned that off, it started working. Here is the SELinux denial from the logs:

node=cauchy type=AVC msg=audit(07/19/2023 14:03:10.854:1101750) : avc: denied { execute } for pid=3575990 comm=sh name=sendmail.postfix dev=“dm-1” ino=402654539 scontext=system_u:system_r:ood_pun_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file permissive=0

Thanks for all the help

We went back to the local smtp configuration, and SELinux isn’t an issue with this one, so we don’t have to create a custom SELinux policy. You can close this ticket