GlobalMutex.LinuxGlobalMutexAdapter uses hardcoded /var/lock directory, which is deprecated in modern Linux and will go away

[rmunn]

On a recently-installed Arch Linux laptop, I ran into an issue where GlobalMutex.LinuxGlobalMutexAdapter threw "SIL.PlatformUtilities.NativeException: An error with the number, 13, ocurred." Error 13 in Linux is EPERM, permission denied.

On investigating, I found that LinuxGlobalMutexAdapter was trying to open a global mutex file in /var/lock. On recent systemd systems, /var/lock is a symlink to /run/lock and /run/lock is considered deprecated, and is expected to go away in systemd release 258 (current systemd release is 256). This comment from Lennart Poettering explains why:

"It [that is, /run/lock] is inherently legacy, and I can only advise your software to place the lock it needs in a more appropriate place, for example /run/$yoursoftware/ somewhere. These directories are typically generated via tmpfiles or RuntimeDirectory= and have the benefit that they are not a shared namespace, but a private one, and thus not prone to the security issues.

Sorry, but /run/lock/ really should die, there's zero benefit of using that dir over a proper, private runtime directory, like everyone else does.

We should update LinuxGlobalMutexAdapter to handle a "permission denied" error in /var/lock and try another path, /run/palaso/lock (creating /run/palaso/lock if it doesn't exist, and assuming that /run/palaso has already been created with appropriate permissions by the appropriate Linux package, e.g. the fieldworks .deb package should include a /usr/lib/tmpfiles.d/palaso-lock.conf file with the contents "d /run/palaso/lock 1777 root root -" so that systemd will automatically create /run/palaso/lock as a sticky-bit directory on bootup). That way we will future-proof any code that uses GlobalMutex on Linux systems, allowing it to continue to work after systemd 258 removes /var/lock support.

(Note: that last line comes from the comment in Arch Linux's conf file setting up /run/lock, which reads as follows:)

# This used to be created by systemd, but is considered part of legacy
# SystemV support, and that in turn will be removed with systemd v258
# ultimately. It is still used by differnt packages, so let's move it
# here... As /run is a tmpfs it has to be created by tmpfiles.
d /run/lock 0755 root root -

[lyonsil]

If we need to change how the Linux global mutex works anyway, it might be worth considering adopting the ExplicitGlobalMutexAdapter on Linux. I think it will work as-is even though it inherits from the Windows mutex. Of course this should be tested first, but it might be less painful than having people create a special directory for things to keep working.

Note that ExplicitGlobalMutexAdapter works properly on macOS (which is *nix at its core), so there is good reason to believe it will work on Linux, too.

[marksvc]

Hey @rmunn , thanks for your work on these things.

My understanding is that /var/lock is already a problem on other Linux distributions.

I expect it would be pretty challenging for a Flatpak package to get a /run/DIR directory created, as that probably requires unusual abilities.

If the mutex is only being used to protect application-level resources, or user-level resources, then that would give us more flexibility in how it is implemented. But if we find that the software really needs the mutex to protect a system-wide resource, which software running by multiple active users on the system can participate in, then a couple options that come to mind, without doing some research, are:

• Flatpak packages could request access to write to sockets in /dev/shm, /tmp, or /var/tmp, if those are on a machine.
• A software application could listen and speak to network ports on the local machine.

And of course, if you just need a user-level mutex, then the Flatpak package could request access to a socket or other file in the user-specific XDG_RUNTIME_DIR, or something on a bus.

the fieldworks .deb package should include a

Some of the traditional libpalaso-using software applications that were published for Linux no longer use .deb packages. Some remaining applications that still publish .deb packages include keyman and adaptit (if those use libpalaso).

[marksvc]

ExplicitGlobalMutexAdapter

It appears that ExplicitGlobalMutexAdapter relies on dotnet System.Threading.Mutex.

I was not sure about dotnet Mutex working across sandboxed applications, but after some brief searching I am optimistic about it working with adequate sandboxing permissions granted. At least for multiple applications running for the same user.

I didn't very quickly see implementation details about how Mutex works to think it would work between different users. But that wouldn't be too hard to test.

[rmunn]

Using /dev/shm as mentioned in the 3301b97 commit message is probably a good idea; it won't survive a reboot, but that's actually a feature when it comes to a global lock file, since the processes that took out the lock will no longer be running after a reboot. Or, of course, using ExplicitGlobalMutexAdapter which I haven't gotten around to testing yet.