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

[socketpair]

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-139184: set O_CLOEXEC for master_fd when call os.forkpty #139408

[socketpair]

P.S. except (AttributeError, OSError): does not check for exact errno in OSError
And also return pid, master_fd in child preoces returns closed file descriptor.

[vstinner]

It's now fixed in Python 3.15. I don't think that it's a good idea to backport such subtle change to stable versions (3.13, 3.14).

[socketpair]

No, another bug connected with implementation:

Since removing O_CLOEXEC is done in parent process, other threads may issue execve() and therefore FD may leak. forkpty() should return FD already with O_CLOEXEC. That's what has been mentioned in description.

Please reopen.

[vstinner]

Ok, I reopen the issue.

Do you want to propose a PR to use posix_openpt()?

[socketpair]

Yes, as an option. On platforms where it's not supported — own implementation (i.e. fixing current one, by adding O_CLOEXEC to open('/dev/ptmx')).