This is the linuxptp part of the issue reported in RHEL-55133. There is a selinux issue with timemaster when using virtual clocks. There is a race condition between udev applying the selinux context to a newly created vclock and ptp4l started by timemaster using that vclock.

type=AVC msg=audit(1723567978.288:35395): avc: denied \{ read write } for pid=1804889 comm="ptp4l" name="ptp8" dev="devtmpfs" ino=55379 scontext=system_u:system_r:ptp4l_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0
type=AVC msg=audit(1723567978.288:35396): avc: denied \{ read write } for pid=1804891 comm="ptp4l" name="ptp9" dev="devtmpfs" ino=55380 scontext=system_u:system_r:ptp4l_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0

timemaster should wait a bit after creating a vclock before starting ptp4l to give udev some time to fix its context.

Please provide the package NVR for which bug is seen:

linuxptp-4.2-2.el9_4.2.x86_64

selinux-policy-38.1.44-1.el9.noarch

How reproducible:

sometimes

Steps to reproduce

1. configure timemaster to use a PTP domain on a machine with PHC (keeping the use_vclocks option at the default of 1)
2. start timemaster
3. observe system log for ptp4l errors and audit log for AVCs

Expected results

ptp4l works, no AVCs reported for ptp4l trying to access /dev/ptp with device_t context

Actual results

AVCs reported, ptp4l fails to start when selinux is in enforcing mode