`--lock-file` doesn't seem to lock?

[WhyNotHugo]

Simple example:

bwrap --dev-bind / / --lock-file /tmp/my-lock bash

If I run this once, I'd expect a lock to be taken on the file, and the second instance to not start. Instead, running a second instance of the same command runs normally.

Am I missing something in how --lock-file work?

[rusty-snake]

Precondition: The lock file must exist. Bubblewrap will not create it.

Bubblewrap takes a shared lock (man 2 fcntl) on the file, therefore multiple instances can create a lock on the same file.

If you patch bubblewrap to take an exclusive lock, only one instance is allowed. However this check has a race - because the check happens after forking I guess - and the command is started and killed just afterwards. Very short living programs like echo "Hello" will run completely.

exclusive-lock.patch

diff --git a/bubblewrap.c b/bubblewrap.c
index eece9d8..943f65d 100644
--- a/bubblewrap.c
+++ b/bubblewrap.c
@@ -582,12 +582,12 @@ do_init (int event_fd, pid_t initial_pid)
 
   for (lock = lock_files; lock != NULL; lock = lock->next)
     {
-      int fd = open (lock->path, O_RDONLY | O_CLOEXEC);
+      int fd = open (lock->path, O_WRONLY | O_CLOEXEC);
       if (fd == -1)
         die_with_error ("Unable to open lock file %s", lock->path);
 
       struct flock l = {
-        .l_type = F_RDLCK,
+        .l_type = F_WRLCK,
         .l_whence = SEEK_SET,
         .l_start = 0,
         .l_len = 0

[WhyNotHugo]

This lock doesn't seem to be what I'm looking for.

However this check has a race - because the check happens after forking I guess - and the command is started and killed just afterwards. Very short living programs like echo "Hello" will run completely.

Weird; sounds like the lock should be taken before starting the command. Isn't this a bug (e.g.: using a racey lock)?

[smcv]

This lock doesn't seem to be what I'm looking for.

Probably not. Taking an open file description lock outside the sandbox and using --sync-fd to ask bubblewrap to hold the lock open for you as long as it's running is probably more practically useful. That gives you control over:

• whether the lock is an exclusive ("write") or shared ("read") lock
• which of the various incompatible flavours of lock you're using (process-associated locks are not useful across a process boundary, but you might use either Linux OFD locks or POSIX flock(2) locks, and anyone who needs to interoperate with your use of locking has to know which one you're using so that they can do the same)
• the lock's full lifetime, including times at which bubblewrap can't possibly do anything useful about locking because it isn't even running yet (for example while your larger component that uses bubblewrap, such as Flatpak, decides what app it is going to run and takes out enough locks to prevent that app from getting deleted out from under it)

At the moment only one --sync-fd option can be used. If you need more than one, you could contribute a new --add-sync-fd option, similar to the relationship between --seccomp and --add-seccomp-fd?

Isn't this a bug (e.g.: using a racey lock)?

It's clearly not meant to be used to exclude access to a resource, which seems to be what you want to do, because if it was, it would be exclusive rather than shared.

bubblewrap was originally part of Flatpak, so the design was probably for --lock-file to be used to take out a shared lock on the .ref file that Flatpak uses to avoid deleting an app or runtime that is in use, with destructive operations like flatpak uninstall taking out an exclusive lock on the same file before deletion.

However, I don't see a way for the bwrap --lock-file API to do that without a race anyway, because in the time window between a flatpak run process deciding to use a particular runtime or app version and its associated bwrap process taking the lock, a parallel flatpak uninstall process might have decided to remove that runtime or app, resulting in bwrap failing before it has an opportunity to lock the file. There is nothing bwrap can do to solve that, because bwrap isn't necessarily even running yet! If Flatpak wants that locking model, then I suspect it will need to already be holding a lock while it decides what arguments it is going to pass to bwrap.

If nobody can think of a situation where --lock-file is useful, the answer might be that use of --lock-file is a bug.

[smcv]

Or, if the program that you're wrapping with bwrap needs to interact with the lock, you could take out a lock on a fd and pass it down to that program, and do whatever locking you want to do on that fd, without bwrap's involvement. That would bind the lifetime of the lock fd to the lifetime of your wrapped program, rather than the lifetime of bwrap.

[WhyNotHugo]

I mostly wanted a simple way to avoid multiple instances of a bwrap'd command.

I don't think this lock is quite right, and just wrapping the bwrap call in flock works well enough for me.

Thanks for all the info here! I'll go ahead and close this, but it seems there's a general sentiment that the flag should be dropped entirely. Do you want a separate issue for that?