os.forkpty() and pty.fork() return FD with O_CLOEXEC

Bug report

Bug description:

(pid, fd) = pty.fork() # os.forkpty()
print('os.get_inheritable(fd))

https://docs.python.org/3/library/os.html#os.forkpty
https://docs.python.org/3/library/pty.html#pty.fork

Say nothing about that.

Lib/pty.py:

def fork():
    """fork() -> (pid, master_fd)
    Fork and make the child a session leader with a controlling terminal."""

    try:
        pid, fd = os.forkpty()
    except (AttributeError, OSError):
        pass
    else:
        if pid == CHILD:
            try:
                os.setsid()
            except OSError:
                # os.forkpty() already set us session leader
                pass
        return pid, fd

    master_fd, slave_fd = openpty()
    pid = os.fork()
    if pid == CHILD:
        os.close(master_fd)
        os.login_tty(slave_fd)
    else:
        os.close(slave_fd)

    # Parent and child process.
    return pid, master_fd

Also uses openpty() which also does not set O_CLOEXEC

Meanwhile, there is a C function posix_openpt(int flags); which allows setting O_CLOEXEC.

Seems, fd-leak safe solution is to boilerplate all the actions by hand. i.e. same way as pty.fork() does, but also implement openpty() using posix_openpt() + ptsname() / ptsname_r().

Just setting O_CLOEXEC after openpty() or after calling C forkpty() is not enough because of race-condition and possible file descriptor leak.

So, CLOEXEC behavior should be documented and race-condition prevented

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-139408

Inizia con Lib/pty.py e con i punti di ingresso documentati os.forkpty() e pty.fork(), quindi confronta i relativi percorsi openpty() con l’interfaccia posix_openpt(int flags) menzionata nel report. Il lavoro è completo quando il comportamento di CLOEXEC è documentato e i percorsi fork/openpty impediscono la fuga di descrittori di file dovuta alla race condition descritta.