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

From: Michael Forney <mforney_AT_mforney.org>
Date: Sun, 6 Mar 2022 15:14:00 -0800

On 2022-03-06, Arthur Williams <taaparthur_AT_disroot.org> wrote:
> Yeah I noticed that it wasn't defined in POSIX (which makes me wounder
> why it is here in sbase and not ubase). To clarify what I meant, there
> are popular implementations that don't have the '-F' flag (like busybox)
> and adding it would just encourage people to write code that didn't work
> in many environments. And this may be fine if there was some benefit,
> but I just don't see the any positives of forking.
>
> But if we agree it isn't incorrect to not fork, any objection to the
> patch?

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.
- 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.

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.

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.
Received on Mon Mar 07 2022 - 00:14:00 CET