Hello,

I think this is caused by the recent capability dropping feature.
I assume that rsyslog is running as root by default on your system. The /usr/bin/a.sh file has read/write/execute permission bits set for the owner of the file. However, when omprog creates a fork to be able to execute the program in the background, the capabilities are not inherited. Due to that the following happens:
1. /usr/bin/a.sh is owned by bin:bin
2. the file has no permission bits set for group/others
3. rsyslog is not the owner of the file
4. Results in not being able to execute the prog.

Imagine if user with ID of "bin" was compromised, it could easily modify the content of your prog, perform some malicious activity. I recommend to change the ownership of the a.sh prog or use the workaround that you suggested.

Hi:
   Thanks a lot for your explanation. Indeed rsyslog is running as root by default under RHEL.I think I will change the owner of the program to root to solve the problem. Thanks again for your help!

Hi
   After further testing, unfortunately the script can not work under current design. my script need to write analyze result to non-root files for non-root process to read. under current "capability dropping" design, the script has limit below:

1. the script must own by root or world executable (eg: permission 755)
2. the script can only write root-owner directory or world writable directory (eg: permission 777)

   It seems a very strange design and I don't know how to workaround it. I tried suid and sudo (which rsyslog refuse to run) but nothing works. the script seems running under user "root" but has no root privilege. 

   Finally I can only downgrade to RHEL 9.0 version (rsyslog-8.2102.0-101.el9_0.1) to restore the previous working behavior.

   My RHEL 9.2/Stream testing config like below:

======
>cat /etc/rsyslog.d/example.conf
module(load="omprog")
*.* action(type="omprog" binary="/usr/bin/a.sh" output="/tmp/result.log)

>cat /usr/bin/a.sh
#!/bin/bash
whoami
whoami >/tmp/test/me
while true;do
        sleep 1
done

>mkdir /tmp/test; chmod 700 /tmp/test; chown bin.bin /tmp/test; systemctl restart rsyslog

>cat /tmp/result.log
root
/usr/bin/a.sh: line 3: /tmp/test/me: Permission denied

Hello,

I tried your reproducer and I got the same results for rhel8.9 as well, where the cap dropping feature is not available.

Just a side note, a new version of rsyslog will contain libcapng.default global directive, which turns off this feature, upstream: https://www.rsyslog.com/doc/master/rainerscript/global.html#libcapng-default

Hi:
   Do you mean your rhel 8.9 get "Permission denied" result also?
   I have tried the versions below:

   8.2102.0-13.el8 (comes with RHEL 8.8) at RHEL 8.8 => script works fine
   8.2102.0-15.el8 (get from stream) at RHEL 8.8 => script works fine
   8.2102.0-105.el9 at RHEL 9.2 => script works fine
   8.2102.0-111.el9 at RHEL 9.2 => script broken and get "Permission denied"

   So look at the changelog between 8.2102.0-105.el9 and 8.2102.0-111.el9. indeed the changelog below seems the reason as you said:

* Mon Nov 21 2022 Attila Lakatos <alakatos> - 8.2102.0-107
- Drop capabilities to only the neccessary set with libcap-ng
  resolves: rhbz#2127404

  8.2102.0-107.el9 was removed from stream so I can not test it to make sure. is there place I can get the version?

Hello,

Thanks for your patience. I did some testing and it turns out that the bounding set was not adjusted when capabilities were dropped.
I made some changes upstream and submitted a PR (I've attached it to this BZ) to fix this problem, feel free to check it out. In the description I've explained why this happens and what can be done to fix this. Thanks. We can backport it if upstream accepts the patch.

In the meantime, could you try the scratch-build out and test whether it works for you? I would appreciate that.
https://kojihub.stream.centos.org/koji/taskinfo?taskID=2813062

Hi:
   Unfortunately the new build didn't work for me. the result is the same as previous 8.2102.0-111 and 8.2102.0-117. I tried several times to make sure. then I downgrade to 8.2102.0-105 to make sure the testing script works again.

   I was using this rpm: https://kojihub.stream.centos.org/kojifiles/work/tasks/3067/2813067/rsyslog-8.2102.0-117.el9.TESTINGONLY.x86_64.rpm

   Thanks for your kind help!

May I ask you to post your reproducer again? Just to be sure. Thanks.

Hi:
   ok. the testing environment is RHEL 9.2 under rsyslog >= 8.2102.0-107 with files below:

=========
>cat /etc/rsyslog.d/example.conf
module(load="omprog")
*.* action(type="omprog" binary="/usr/bin/a.sh" output="/tmp/result.log)

>cat /usr/bin/a.sh
#!/bin/bash
whoami
whoami >/tmp/test/me
while true;do
        sleep 1
done

>ls -la /usr/bin/a.sh
-rwx------ 1 root root 68 Sep  6 00:24 /usr/bin/a.sh


>rm -f /tmp/result.log; rm -rf /tmp/test; mkdir /tmp/test; chmod 700 /tmp/test; chown bin.bin /tmp/test; systemctl restart rsyslog

>cat /tmp/result.log
root
/usr/bin/a.sh: line 3: /tmp/test/me: Permission denied

>cat /tmp/test/me
cat: /tmp/test/me: No such file or directory
=========


when the script works correctly under 8.2102.0-105:
>cat /tmp/result.log
root

>cat /tmp/test/me
root

I accidentally did not backport the entire patch from upstream PR. Now it should be fixed. Please try again with:
https://kojihub.stream.centos.org/koji/taskinfo?taskID=2837242

Let me know if you have selinux enabled. If yes, are there any AVCs?

Hi:
   the new rpm is working fine. I don't have selinux enabled (selinux=0 as boot parameter).
   It works under the testing environment and our original script also works fine.
   thanks again for your kind help!

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.