debian (1.2.22-3~bpo8+1) package build failure

[Olly Betts]

On Sat, Aug 06, 2016 at 03:43:48AM +0000, Eric Wong wrote:
> Eric Wong <e at 80x24.org> wrote:
> > I'm trying to test a trivial patch to set FD_CLOEXEC on the
> > flintlock lockfd when using F_OFD_SETLK
> 
> Fwiw, this is the patch I was originally going to test.
> (but now I see maybe my F_SETFD might only need to be
>  called on F_OFD_SETLK success)   Description at bottom.
> 
> --- a/backends/flint_lock.cc
> +++ b/backends/flint_lock.cc
> @@ -108,6 +108,10 @@ FlintLock::lock(bool exclusive, string & explanation) {
>  	return ((errno == EMFILE || errno == ENFILE) ? FDLIMIT : UNKNOWN);
>      }
>  
> +#ifdef FD_CLOEXEC
> +    (void)fcntl(lockfd, F_SETFD, FD_CLOEXEC);
> +#endif
> +

This is fixed in master and 1.4.0, which set CLOEXEC for all relevant
FDs.  Those changes weren't backported as they were rather pervasive
and we'd had no user reports of issues due to this, but since the
CLOEXEC changes we now we lock in process on a modern Linux kernel and
that change got backported - as you've noticed that can cause more major
issues without CLOEXEC, and I think we ought to backport CLOEXEC for the
lock file to 1.2.x.

I'd suggest comparing backends/flint_lock.cc with the version on git
master - the CLOEXEC-related changes are easy to see, and a bit more
rigorous than your patch (CLOEXEC is applied when the lock file is
opened, at least on platforms which support that, which means there's
no window in which fork()+exec() can occur in another thread while
the FD is unprotected).

Arguably we ought to avoid using OFD locks if we don't have CLOEXEC
(then we use a child process to hold the lock, which also means that
fork()+exec() doesn't end up with a locked FD open).  Currently
only Linux supports OFD locks, and has CLOEXEC so right now it's
not an issue.  OFD locks have been proposed for POSIX standardisation,
but since CLOEXEC is in POSIX.1-2008, I suspect any platform which adds
support for OFD locks would actually support CLOEXEC anyway.

Cheers,
    Olly