Re: [PATCH 1/3] treewide: Add SOCK_CLOEXEC to accept() calls that are missing it

On Wed, May 20, 2026 at 02:37:02AM +0200, Stefano Brivio wrote:

On Mon, 18 May 2026 12:28:57 +1000 David Gibson wrote:

...

On Sat, May 16, 2026 at 05:46:11PM +0200, Stefano Brivio wrote:

...

On Wed, 13 May 2026 14:14:21 +1000 David Gibson wrote:

...

Generally we try to set the O_CLOEXEC flag on every fd we create. This seems to be generally accepted security best practice these days, and we never fork(), so certainly have no need to pass fds to children.

But we do clone() with CLONE_FILES (even though when we clone() to call execvp() later, we don't set CLONE_FILES), so, even though I don't see a reason to skip O_CLOEXEC for c->fd_tap, this conclusion shouldn't be automatic from the fact we don't fork().

So, I did think about that when wrote it, but went for the short version rather than saying clone() with CLONE_FILES doesn't count.

Now, I realised that we've both fallen for the trap again, forgetting that this has nothing to do with fork() or clone() and is, as it says right there in the name, about exec().

No, wait, I didn't fall for it, not this time. :) That's why I was mentioning that when we call clone() and execvp() later (which would be

Uh...? I'm pretty sure the only execve(2) in the entire program is where we spawn passt.avx2. That's essentially the very first thing we do, long before this point.

the only path that matters), we don't set CLONE_FILES anyway.

CLONE_FILES is irrelevant, it's lost during execve(2). -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson