What is the rationale of setting linux capabilities for the gst-ptp-helper executable?

I am totally new to gstreamer, so please forgive me if this question makes no sense or the answer/explanation is obvious - unfortunately, I did not find anything related to this finding. I have checked the capabilities of the gst-ptp-helper executable on a Fedora 38 and 39:

# getcap /usr/libexec/gstreamer-1.0/gst-ptp-helper
/usr/libexec/gstreamer-1.0/gst-ptp-helper cap_net_bind_service,cap_net_admin,cap_sys_nice=ep

As I had no luck yet to check on any other distribution, this might be not gstreamer-related, but Fedora-related instead; still, it is weird to assign these capabilities for a binary related to gstreamer. I dropped these capabilities manually, and everything depending on the package gstreamer1 seem to work flawlessly: wine, libreoffice, chromium-browser, gedit, torbrowser-launcher, wireshark.

According to gstreamer1-1.22.6-1.fc38 - Fedora Packages on 2023-06-08 the setcap was done on this executable. Doing the detective work, I arrived to ptp-helper: Rewrite in Rust for portability and safety (!3889) · Merge requests · GStreamer / gstreamer · GitLab and here I am stuck - there is information about the cap_sys_nice, but no info about the other capabilities. I am going to contact the authors of these findings, but please give me hints why the assignment of these capabilities would be required. Thank you very much.

The reason for the capabilities is that this helper process has to bind to ports 319/320 for receiving PTP packets, and unfortunately UNIX considers ports < 1024 as privileged.

In addition this process runs at a higher scheduling priority to make it less likely that scheduler jitter influences the timing measurements.

And last, it is listing all network interfaces and their MAC addresses to generate a local PTP clock ID, and to understand on which interfaces it is worthwhile listening for PTP packets.

After the initial setup, all the privileges are dropped and from then on the process runs with normal privileges.

On non-Linux (or without capabilities) this process is running setuid root but later on drops to a different user for the same reason.

The reason why this helper process exists is exactly to restrict access to higher privileges to a small helper process instead of having the main process run with elevated privileges. The helper process is spawned whenever needed and talks to the main process via stdin/stdout/stderr, and basically proxies UDP packets from port 319/320 together with timing measurements when the packets were received/sent over the network.

That seems like a bad idea in general without first understanding why things are the way they are. People are not configuring these things for fun but will have a reason. Fortunately the only thing you’re losing like this is the ability to use a PTP clock from GStreamer.


Thank you, now it makes perfect sense.