Re: [hackers] [sbase][PATCH] flock: call exec without forking

From: Arthur Williams <taaparthur_AT_disroot.org>
Date: Mon, 7 Mar 2022 20:29:54 -0800

On Sun, Mar 06, 2022 at 03:14:00PM -0800, Michael Forney wrote:
> There are a couple of cases I can think of where not forking might not
> be what you want:
> - If the process forks again and then exits, the new child ends up
> holding on to the lock longer than the lifetime of the original
> process. There seems to be a -o flag to close the lock before execing
> the child to prevent this, but this doesn't work if we exec directly.

> The first point made me realize that -o with your patch makes flock(1)
> a no-op. It would take the lock, then release it, and then exec. So if
> we were to apply the patch, I think we'd need to remove the -o option.

Why thank you for answering why '-o' exists. I was originally fine with
getting rid of '-o' too, but the usecase you present seems relevant
enough.

> - It's debatable whether this is a valid thing to do, but if the
> process tries to close all open file descriptors (using something like
> closefrom on OpenBSD), it might end up releasing the lock
> accidentally.

Sounds plausible. I can see why people may want to not let the command
implicitly release its lock.

> Did you check what other implementations of flock(1) do in terms of
> forking, and what options they support? It looks like in addition to
> busybox, NetBSD and FreeBSD both have it.

I have now. Seems like everyone forks and like half (util-linux and
FreeBSD) provide the -F option.


OK you've convinced me that there is reason to keep forking and
that the current behavior of flock is fine.

Thanks,
Arthur
Received on Tue Mar 08 2022 - 05:29:54 CET