Description of problem:

We have a customer getting the following AVC on "sys_admin" capability:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
type=PROCTITLE msg=audit(07/10/2023 16:16:25.141:28612) : proctitle=/usr/libexec/platform-python /usr/libexec/rhsmcertd-worker 
type=SYSCALL msg=audit(07/10/2023 16:16:25.141:28612) : arch=x86_64 syscall=flistxattr success=yes exit=17 a0=0xb a1=0x0 a2=0x0 a3=0x55abcbafc3c0 items=0 ppid=3461560 pid=3462381 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rhsmcertd-worke exe=/usr/libexec/platform-python3.6 subj=system_u:system_r:rhsmcertd_t:s0 key=(null)
type=AVC msg=audit(07/10/2023 16:16:25.141:28612) : avc:  denied  { sys_admin } for  pid=3462381 comm=rhsmcertd-worke capability=sys_admin  scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:system_r:rhsmcertd_t:s0 tclass=capability permissive=0
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This happens everytime the worker tries to list the extended attributes of a file it generated itself just before (flistxattr() syscall):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
3462381 16:16:25.046125 mkdir("/tmp/tmpdir.PoRnyf", 0700) = 0 <0.000078>
3462381 16:16:25.046368 mkdir("/tmp/tmpdir.PoRnyf/repodata", 0775) = 0 <0.000016>
3462381 16:16:25.046411 openat(AT_FDCWD</>, "/tmp/tmpdir.PoRnyf/repodata/repomd.xml", O_RDWR|O_CREAT|O_TRUNC, 0666) = 10</tmp/tmpdir.PoRnyf/repodata/repomd.xml> <0.000044>
 :
3462381 16:16:25.046907 fsetxattr(11</tmp/tmpdir.PoRnyf/repodata/repomd.xml>, "user.Librepo.DownloadInProgress", "1", 1, 0) = -1 EOPNOTSUPP (Operation not supported) <0.000010>
 :
3462381 16:16:25.141675 flistxattr(11</tmp/tmpdir.PoRnyf/repodata/repomd.xml>, NULL, 0) = 17 <0.000050>
3462381 16:16:25.142737 flistxattr(11</tmp/tmpdir.PoRnyf/repodata/repomd.xml>, "security.selinux\0", 17) = 17 <0.000047>
 :
3462381 16:16:25.143532 fremovexattr(10</tmp/tmpdir.PoRnyf/repodata/repomd.xml>, "user.Librepo.DownloadInProgress") = -1 EOPNOTSUPP (Operation not supported) <0.000013>
 :
3462381 16:16:25.146973 unlink("/tmp/tmpdir.PoRnyf/repodata/repomd.xml") = 0 <0.000025>
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This AVC pollutes the audit log because it happens every few seconds.

Digging further, it appears that the AVC happens because the process doesn't have the CAP_SYS_ADMIN capability.
This is usually not an issue unless `/tmp` is a tmpfs file system, in such case the kernel verifies the capability is enabled (fs/xattr.c):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
1041 /*
1042  * xattr LIST operation for in-memory/pseudo filesystems
1043  */
1044 ssize_t simple_xattr_list(struct inode *inode, struct simple_xattrs *xattrs,
1045                           char *buffer, size_t size)
1046 {
1047         bool trusted = capable(CAP_SYS_ADMIN);
 :
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Line 1047 above generates the AVC.

I think the AVC can be safely hidden, but this would be necessary only if the code really needed to implement flistxattr() function calls.
I'm not that sure that this is needed, because I can see, from above strace, that the code blindly creates the extended attribute then deletes it (both operations fail here because tmpfs doesn't support extended attributes) so probably querying the extended attributes is not that useful. But that's just my guess I didn't went up to digging into the sources at all.

Version-Release number of selected component (if applicable):

subscription-manager-1.28.36-2.el8.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Enable `tmp.mount` unit then reboot

   # systemctl enable tmp.mount
   # reboot

2. Wait for rhsmcertd-worker to execute

Actual results:

AVCs popping up

Expected results:

No AVC