On 2019-04-18, Christian Brauner <christian@xxxxxxxxxx> wrote: > > Why O_CLOEXEC? I am just curious, I do not really care. > > I think that having the file descriptor O_CLOEXEC by default is a good > security measure in general. Most of the time you do not want to pass a > file descriptor through exec() (apart from 0,1,2) and it is usually more > of an issue when you accidently do it then when you accidently don't. So > if users really care about passing a pidfd they should do so by removing > the O_CLOEXEC flag explicitly. > (New file descriptors should probably all default to that but that's just > my opinion.) > Another thing is that for a pidfds it makes even more sense to have them > cloexec by default. You don't want to *unintentionally* leak an fd that > can be used to operate on a process. There is another factor as well -- if you want to set O_CLOEXEC in a multi-threaded process you can't be sure that another thread didn't fork in between you getting the fd_install'd and the userspace process setting O_CLOEXEC (leading to the fd leaking outside the current process). This is why a lot of syscalls have a way to get an O_CLOEXEC fd from the outset. So I'm +1 on doing O_CLOEXEC by default -- you can always disable it safely but enabling it safely isn't so simple (and I don't think it makes much sense to add the mechanism to pass PIDFD_CLOEXEC as well, given how tight the flags are getting). -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
