Question What is directory 856085 reported by SELinux ?

[MHC_1]

Server operating system version

Alma Linux 9.7

Plesk version and microupdate number

Obsidian 18.0.77

The Error log also has another Error that is as follows:

2026-04-21 08:49:56

err

setroubleshoot [856156] User-level messages [1]

SELinux is preventing /usr/lib64/plesk-9.0/postfix-sendmail-wrapper from search access on the directory 856085. For complete SELinux messages run: sealert -l dae28979-ea72-4e03-aca5-19b45cf7aa52

This references the "856085" directory, can anyone help me distinguish what this directory is and how to prevent these logs occurring (there's a few of them so far)





For completeness sake here's the full alert:

[root@server ~]# sealert -l dae28979-ea72-4e03-aca5-19b45cf7aa52
SELinux is preventing /usr/lib64/plesk-9.0/postfix-sendmail-wrapper from search access on the directory 856802.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that postfix-sendmail-wrapper should be allowed search access on the 856802 directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sendmail' --raw | audit2allow -M my-sendmail
# semodule -X 300 -i my-sendmail.pp


Additional Information:
Source Context                system_u:system_r:sendmail_t:s0
Target Context                system_u:system_r:procmail_t:s0
Target Objects                856802 [ dir ]
Source                        sendmail
Source Path                   /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
Port                          <Unknown>
Host                          server.co.uk
Source RPM Packages           plesk-mail-pc-driver-18.0-2.redhat.9+p18.0.77.2+t2
                              60415.1740.x86_64
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-38.1.65-1.el9_7.1.noarch
Local Policy RPM              selinux-policy-targeted-38.1.65-1.el9_7.1.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     server.co.uk
Platform                      Linux server.co.uk
                              5.14.0-570.55.1.el9_6.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Tue Oct 21 05:27:51 EDT 2025
                              x86_64 x86_64
Alert Count                   18541
First Seen                    2026-02-24 17:41:28 UTC
Last Seen                     2026-04-21 08:52:05 UTC
Local ID                      dae28979-ea72-4e03-aca5-19b45cf7aa52

Raw Audit Messages
type=AVC msg=audit(1776761525.81:2319904): avc:  denied  { search } for  pid=856807 comm="sendmail" name="856802" dev="proc" ino=729829807 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:procmail_t:s0 tclass=dir permissive=0


type=SYSCALL msg=audit(1776761525.81:2319904): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffff9c a1=7ffc08cbc320 a2=0 a3=0 items=0 ppid=856802 pid=856807 auid=4294967295 uid=30 gid=30 euid=0 suid=0 fsuid=0 egid=30 sgid=30 fsgid=30 tty=(none) ses=4294967295 comm=sendmail exe=/usr/lib64/plesk-9.0/postfix-sendmail-wrapper subj=system_u:system_r:sendmail_t:s0 key=(null)

To underline;

Can you help distinguish the exact path / directory referenced and can you help inform how to prevent this access cause in future if access shouldn't be happening?

 

[scsa20]

It's actually the process that's runs in /proc (so in this case /proc/856807).

I personally usually don't have SELinux enabled but if you want to keep it on then you can make a SELinux policy module by doing the following:

ausearch -c 'sendmail' --raw | audit2allow -M my-sendmail
semodule -X 300 -i my-sendmail.pp

This basically tells SELinux that sendmail is good no matter the process ID was created.

 

[MHC_1]

@scsa20 thank you.

It's actually the process that's runs in /proc (so in this case /proc/856807).

I am not too bothered about having SELinux on or off (I simply don't know enough) but I was more curious as to if it's a known issue for SELinux to find false positives for "postfix-sendmail-wrapper" or if this particular wrapper/instance could be a problem.

How could I dig down and diagnose the cause of this SELinux flag and then in turn decide if this is a correct or false positive by SELinux?