[pbs-devel] [PATCH proxmox] sys: fs: set FD_CLOEXEC when creating temp files

[Fabian Grünbichler]

> Dominik Csapak <d.csapak at proxmox.com> hat am 29.11.2024 09:02 CET geschrieben:
> On 11/29/24 08:57, Fabian Grünbichler wrote:
> >> Dominik Csapak <d.csapak at proxmox.com> hat am 28.11.2024 15:54 CET geschrieben:
> >> @@ -128,7 +128,10 @@ pub fn make_tmp_file<P: AsRef<Path>>(
> >>       let mut template = path.to_owned();
> >>       template.set_extension("tmp_XXXXXX");
> >>       let (mut file, tmp_path) = match unistd::mkstemp(&template) {
> >> -        Ok((fd, path)) => (unsafe { File::from_raw_fd(fd) }, path),
> >> +        Ok((fd, path)) => {
> >> +            nix::fcntl::fcntl(fd, FcntlArg::F_SETFD(FdFlag::FD_CLOEXEC))?;
> >> +            (unsafe { File::from_raw_fd(fd) }, path)
> >> +        }
> > 
> > unfortunately, this is still racy since the FD is open with O_CLOEXEC between the unistd::mkstemp and the fcntl - see the man page of fcntl which explicitly calls this out:
> > 
> > "In  multithreaded programs, using fcntl() F_SETFD to set the close-on-exec flag at the same time as another thread performs a fork(2) plus execve(2) is vulnerable to a race condition that may unintentionally leak the file descriptor to the program executed in the child process."
> > 
> > we could use libc::mkostemp (unsafe, path/template+flags -> raw fd or error as c_int) instead? and/or we could write a wrapper around it and propose it upstream for nix inclusion? ;) but since this seems to be the only place where we call mkstemp..
> > 
> 
> yeah had the same though, and have a version here where i basically copied nix's mkstemp but with 
> oflags + mkostemp call to libc, so i can send that if wanted
> 
> the question for me is if it's ok to use since mkostemp is only a glibc extension (since 2.7) and we
> may use that in proxmox-backup-client which we want to statically build ?
> (not sure how that static compilation works with such a thing though...)

that's a fair argument, if we want that it looks like we'd have to reimplement mkostemp ourselves I guess.. or we abandon this approach and evaluate allow-listing FDs we want to keep, and closing all others on fork..  but then we have to ensure no forking ever happens outside of our immediate control, which seems kinda annoying as well..