<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en">
<head>
<meta content="text/html; charset=US-ASCII" http-equiv="Content-Type">
<title>
GitLab
</title>
<style>img {
max-width: 100%; height: auto;
}
</style>
</head>
<body>
<div class="content">
<p class="details" style="font-style: italic; color: #777;">
<a href="https://gitlab.com/Courmisch">Remi Denis-Courmont</a> created an issue:
</p>
<div></div>
<h2 dir="auto">
<a id="user-content-description-of-problem" class="anchor" href="#description-of-problem" aria-hidden="true"></a>Description of problem:</h2>
<p dir="auto">A program using GnuTLS might (outside GnuTLS) spawn a child process. With POSIX systems, a multithread application can do this either via <code>fork()</code> then an <code>exec*()</code> family function, or via a <code>posix_spawn*()</code> 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.</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">POSIX.next specifies the "e" open flag for the <code>fopen()</code>, for instance <code>fopen(file, "re")</code>, and the <code>SOCK_CLOEXEC</code> socket type mask for <code>socket()</code>, for instance. POSIX.2008 already specifies <code>O_CLOEXEC</code> for the <code>open()</code> call.</p>
<p dir="auto">This is not a problem for the tests and sample programs in GnuTLS, but it is a problem for the few <code>fopen()</code> calls within the library itself.</p>
<h2 dir="auto">
<a id="user-content-version-of-gnutls-used" class="anchor" href="#version-of-gnutls-used" aria-hidden="true"></a>Version of gnutls used:</h2>
<p dir="auto">3.6.13-49-g<a href="https://gitlab.com/gnutls/gnutls/-/commit/d51399272886d909fbc40f2c5e26db3e87a45a0a" data-original="d51399272" data-link="false" data-link-reference="false" data-project="179611" data-commit="d51399272886d909fbc40f2c5e26db3e87a45a0a" data-reference-type="commit" data-container="body" data-placement="top" data-html="true" title="Merge branch 'tmp-siv' into 'master'" class="gfm gfm-commit has-tooltip">d5139927</a></p>
<h2 dir="auto">
<a id="user-content-distributor-of-gnutls-eg-ubuntu-fedora-rhel" class="anchor" href="#distributor-of-gnutls-eg-ubuntu-fedora-rhel" aria-hidden="true"></a>Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)</h2>
<p dir="auto">upstream</p>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #777;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/-/issues/985">view it on GitLab</a>.
<br>
You're receiving this email because of your account on gitlab.com.
If you'd like to receive fewer emails, you can
<a href="https://gitlab.com/-/sent_notifications/4fb69a6d71e36a84e07e2f1cba136e0e/unsubscribe">unsubscribe</a>
from this thread or
adjust your notification settings.
<script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":"View Issue","url":"https://gitlab.com/gnutls/gnutls/-/issues/985"}}</script>
</p>
</div>
</body>
</html>