Add FDs to a process' FD table when transferred via SCM_RIGHTS

[bawhetst]

Motivation

While debugging an issue with missing FDs for an HAProxy process in the Sysdig Agent, we found that HAProxy utilizes the SCM_RIGHTS functionality to do hitless reloads when the HAProxy config changes. You can read more about that at https://blog.cloudflare.com/know-your-scm_rights/, https://man7.org/linux/man-pages/man7/unix.7.html, and https://copyconstruct.medium.com/file-descriptor-transfer-over-unix-domain-sockets-dcbbf5b3b6ec. To summarize them, SCM_RIGHTS allows processes to transfer open file descriptors between themselves via control messages in the sendmsg() and recvmsg() syscalls.

In looking at the library code, I don't see this functionality being handled at either the driver or userspace layer. Because of this, the FDs that are transferred to a process via SCM_RIGHTS do not show up in the FD table for that process until restarting the Agent. After restarting, the FDs appear since they are found during the initial procfs scan.

Feature

When open FDs are transferred to a process via SCM_RIGHTS, I'd like to see those FDs show up in the process' FD table.

At the driver layer, we'll need to return a new argument for recvmsg() which will be the control messages from msghdr. Those are fields msg_control and msg_controllen in the msghdr.

Then, in sinsp_parser::parse_rw_exit(), we need to check for SCM_RIGHTS control messages for recvmsg() syscalls. If we detect one, we need to extract the FDs out of it, lookup the FDs in procfs to construct their fdinfo, and add them to the FD table for the process.

Alternatives

Beyond a periodic procfs rescan, there's not really much else we can do to handle SCM_RIGHTS.

Additional context

The Sysdig Jira issue where this was found and discussed is SMAGENT-5353.

[FedeDP]

Hi! Thanks for such an in-depth analysis!
Yep this feat request totally makes sense; would you be willing to tackle it? :)

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[FedeDP]

This was actually fixed in #1400.
/close

[poiana]

@FedeDP: Closing this issue.

In response to this:

This was actually fixed in #1400.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.