Sending FDs over UNIX domain sockets

[Fabiano Sidler]

Hi folks!

I'm trying to pass some file descriptors over a UNIX domain socket.
But either I'm doing something wrong, or there is a bug in Python.
Here's my code:


=== testclient start ===
#!/usr/bin/env python3

from socket import socket, AF_UNIX, SOCK_STREAM, send_fds
import sys

path = '/tmp/test'

s = socket(AF_UNIX, SOCK_STREAM)
s.connect(path)
send_fds(s, [bytes()], [
    sys.stdin.fileno(),
    sys.stdout.fileno(),
    sys.stderr.fileno()
], 3, None)
=== testclient end ===


=== testserver start ===
#!/usr/bin/env python3

from socket import socket, AF_UNIX, SOCK_STREAM, recv_fds
from os.path import exists
from os import remove

path = '/tmp/test'

s = socket(AF_UNIX, SOCK_STREAM)
if exists(path):
    remove(path)
s.bind(path)
s.listen(-1)
c,_ = s.accept()
fds = recv_fds(c, 1024, 3)
print(fds)
=== testserver end ===


What's the issue?

Best wishes,
Fabiano

--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: zipapp: add compression (method), compresslevel options from Zipfile

[Abdur-Rahmaan Janhangeer via Python-list]

You have some demo code for it?


Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius

On Mon, 10 Nov 2025, 07:18 Mingye Wang via Python-list, <
python-list@python.org> wrote:

> Zipapp is meant to produce things that will be delivered to an end-user.
> In this way it should behave like most packaging tools and offer more
> "thorough" compression options, limited only by the version of the Python
> interpreter on the user's side (more specifically, their zipfile modules).
> As a result I believe we should be allowed to choose the compression method
> and compression level. Some seconds spent on the developer's computer can
> be minutes saved on downloading from a poor Internet connection.
>
> My proposed API surface include two keyword-only parameters, compression
> and compresslevel, both having the same meaning and type as their Zipfile
> counterparts. The compression option should take precedence over the
> current boolean "compressed" option if it is not set to None; otherwise the
> settings, including the defaults for "compressed" apply.
> --
> https://mail.python.org/mailman3//lists/python-list.python.org
>
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Sending FDs over UNIX domain sockets

[Grant Edwards via Python-list]

On 2025-11-16, Pokemon Chw via Python-list  wrote:

> On Linux AF_UNIX + SOCK_STREAM sockets, there is a quirk in how the
> kernel handles control messages with SCM_RIGHTS:
>
> To successfully pass file descriptors via SCM_RIGHTS, you must send
> at least one byte of normal data in the same sendmsg()
> call. Otherwise, the control message (i.e., the file descriptors)
> will not actually be transmitted.

Very interesting! If I ever knew that I had completely forgotten it.
Apparently that's not true on Mac OS-X where there must be at least
one iovec entry, but that entry can contain zero bytes.

FWIW, here is the relevent portion of the Linux man page Unix(7):

  Ancillary messages
  
Ancillary data is sent and received using sendmsg(2) and
recvmsg(2).  For historical reasons, the ancillary message types
listed below are specified with a SOL_SOCKET type even though they
are AF_UNIX specific.  To send them, set the cmsg_level field of
the struct cmsghdr to SOL_SOCKET and the cmsg_type field to the
type.  For more information, see cmsg(3).

SCM_RIGHTS

  Send or receive a set of open file descriptors from another
  process.  The data portion contains an integer array of the file
  descriptors.

  Commonly, this operation is referred to as "passing a file
  descriptor" to another process.  However, more accurately, what
  is being passed is a reference to an open file description (see
  open(2)), and in the receiving process it is likely that a
  different file descriptor number will be used.  Semantically,
  this operation is equivalent to duplicating (dup(2)) a file
  descriptor into the file descriptor table of another process.

  If the buffer used to receive the ancillary data containing file
  de‐ scriptors is too small (or is absent), then the ancillary
  data is truncated (or discarded) and the excess file descriptors
  are automati‐ cally closed in the receiving process.

  If the number of file descriptors received in the ancillary data
  would cause the process to exceed its RLIMIT_NOFILE resource
  limit (see getrlimit(2)), the excess file descriptors are
  automatically closed in the receiving process.

  The kernel constant SCM_MAX_FD defines a limit on the number of
  file descriptors in the array.  Attempting to send an array
  larger than this limit causes sendmsg(2) to fail with the error
  EINVAL.  SCM_MAX_FD has the value 253 (or 255 before Linux
  2.6.38).

   [...]

   At least one byte of real data should be sent when sending
   ancillary data.  On Linux, this is required to successfully send
   ancillary data over a UNIX domain stream socket.  When sending
   ancillary data over a UNIX domain datagram socket, it is not
   necessary on Linux to send any accompanying real data.  However,
   portable applications should also include at least one byte of real
   data when sending ancillary data over a datagram socket.
-- 
https://mail.python.org/mailman3//lists/python-list.python.org