Jailed FreeBSD needs BOOST_INTERPROCESS_FILESYSTEM_BASED_POSIX_SHARED_MEMORY

[Jim Bell <jim@…>]

Note that one of the FreeBSD test platforms is failing many interprocess tests (both trunk and release), while the other passes. The one failing is in a ​Jailed environment (the other one isn't), and all failures seem to involve "access denied" (EPERM).

Jails deliberately impose ​some restrictions on shared memory.

If I modify BOOST_INTERPROCESS_FILESYSTEM_BASED_POSIX_SHARED_MEMORY (defined in interprocess/detail/workaround.hpp, lines 102) to be defined under FreeBSD <= 8, I'm able to change a test from failing to passing.

I'm not sure there's a way to tell if we're in a jail during compile. And even if we could, there would be a binary compatibility issue moving an executable built in a non-jailed environment to a jailed one.

Is there a benefit to having this flag set one way or the other?

[Jim Bell <jim@…>]

That's "Permission denied" (e.g., here).

[Jim Bell <jim@…>]

sysctl shows:

security.jail.sysvipc_allowed: 0

[Ion Gaztañaga]

BOOST_INTERPROCESS_FILESYSTEM_BASED_POSIX_SHARED_MEMORY changes the way shared memory name is created from a user defined name. If true, the name is based on a temporary file. I don't know why this file-based name works and the classic one (/shm_name) fails.

If we want to maintain binary interface, we will need to check for the jailed environment in runtime and change shm name behaviour in runtime.

I'd need a bit of help to know how a process can check if it's working in a jailed environment using freebsd C api. Maybe sysctl (2)?

[Ion Gaztañaga]

I've updated trunk code so that FreeBSD >= 7 will check at runtime "security.jail.jailed = 1" to use filesystem based posix shared memory. I'll need help to check if that workaround works or if it needs some changes.

[Jim Bell <jim@…>]

I ran both jailed and non-jailed regression tests last night and your fix works for both, as you can see. Note that the jailed test (FBSD-64) now passes ALL interprocess tests. Excellent!

Curious that the non-jailed trunk test (FBSD-32) fails a single interprocess test (managed_shared_memory_test), with exactly the same symptom as the jailed test failures (throwing boost::interprocess::interprocess_exception: 'Permission denied'). I don't recall if that was happening before. Either way, it seems like a separate ticket.

[anonymous]

That failure is related to a FreeBSD bug with copy on write mapping of share memory. See:

​http://www.freebsd.org/cgi/query-pr.cgi?pr=150260

[Ion Gaztañaga]

Fixed in trunka and release branches