[gnutls-devel] GnuTLS | GnuTLS leaks file descriptors in child processes (#985)

[Development of GNU's TLS library]

Remi Denis-Courmont created an issue: https://gitlab.com/gnutls/gnutls/-/issues/985



## Description of problem:
A program using GnuTLS might (outside GnuTLS) spawn a child process. With POSIX systems, a multithread application can do this either via `fork()` then an `exec*()` family function, or via a `posix_spawn*()` family function. First (at fork time), the child process is created and inherits all the file descriptors of the parent. Then (at exec time), the file descriptors marked with the close-on-exec flag are closed; others are left open in the new executed program.

To avoid leaks, all file descriptors should be marked close-on-exec (unless explicitly intended to be inherited). The program cannot know what file descriptors GnuTLS has opened, so GnuTLS has to set the flag. Furthermore because the application might have one thread using GnuTLS while another is forking, the flag must be set "atomically" while file descriptor is being allocated.

Consequences of not closing the file descriptors vary with the type. For regular files, this can prevent un-mounting a file system. In the worst case, it might lead to privilege escalation if the child process has different privileges than the parent.

POSIX.next specifies the "e" open flag for the `fopen()`, for instance `fopen(file, "re")`, and the `SOCK_CLOEXEC` socket type mask for `socket()`, for instance. POSIX.2008 already specifies `O_CLOEXEC` for the `open()` call.

This is not a problem for the tests and sample programs in GnuTLS, but it is a problem for the few `fopen()` calls within the library itself.

## Version of gnutls used:
3.6.13-49-gd51399272

## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)
upstream

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/985
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200507/6cbda98b/attachment.html>