Support Socket.DuplicateAndClose through pidfd_getfd on Linux

[NinoFloris]

Related: #1760

Syscall:
https://man7.org/linux/man-pages/man2/pidfd_getfd.2.html

It should be possible to use this syscall to implement DuplicateAndClose, it seems with it Linux no longer fundamentally differs from Windows' WSADuplicateSocket. Though I can imagine the ptrace permission requirement may be problematic.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[mconnew]

FYI, this would be enable implementing NetTcp port sharing in a way which works on Windows and Linux for CoreWCF when I get to implementing that feature.

[antonfirsov]

ptrace permission requirement may be problematic.

That requirement makes me think pidfd_getfd() rather exists for implementing things like isolation or debugging, and using it for implementing multi-process servers (the typical use-case for DuplicateAndClose()) would be unusual, maybe even unprecedental and might burn users with permission issues.

[fbrosseau]

The more common and universal way to implement this feature is with sendmsg/recvmsg and SCM_RIGHTS. It's slightly more involved because it requires setting up a unix-domain socket to make the transfer, but it will work everywhere.

[NinoFloris]

We are aware, but it fundamentally doesn't fit with the way the windows model works. Primarily because it needs cooperation from both processes.

[fbrosseau]

It doesn't fit the shape of DuplicateHandle/wsaduplicatesocket alone (while pidfd_getfd does, yes), but I feel like for scenarios as advanced as WCF wants to do (multiprocess port sharing), having a higher level abstraction that completes whatever handshake is necessary to allow for passing around handles between a parent process and its children (yes, with cooperation/knowledge of the other side) may be preferrable to trying to match the DuplicateAndClose pattern 1:1.

Permission bits are really messy to deal with (when possible at all), especially in containers.

[antonfirsov]

The more common and universal way to implement this feature is with sendmsg/recvmsg

I also prefer following established practices and avoid exposing users to permission issues. I don't think it's possible to create a reliable cross-platform API here and the FD migration feature request is already tracked by #932 and #48637.

My preference would be to close this as not planned, @wfurt yay or nay?

[NinoFloris]

Sure this wasn't opened because I personally need it, or because there are no other alternatives. I happened to come across it and opened the issue to make sure the team is aware that this syscall exists, I did not.

[wfurt]

I don't have strong preference @antonfirsov. While I feel we may not expose it directly we can leave it around as implementation detail. My primary concern would be dependency on. PTRACE_MODE_ATTACH_REALCREDS. It probably deserves some research to see if that would be common enough to explore it.