Boost C++ Libraries: Ticket #4694: Jailed FreeBSD needs BOOST_INTERPROCESS_FILESYSTEM_BASED_POSIX_SHARED_MEMORY

Wed, 29 Sep 2010 14:23:51 GMT

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

Wed, 29 Sep 2010 14:30:08 GMT

sysctl shows:

security.jail.sysvipc_allowed: 0

Ion Gaztañaga — Sat, 09 Oct 2010 12:05:02 GMT

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 — Sat, 09 Oct 2010 16:51:42 GMT

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.

Tue, 12 Oct 2010 13:42:14 GMT

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 — Tue, 12 Oct 2010 16:12:36 GMT

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

status changed; resolution set

Ion Gaztañaga — Tue, 12 Oct 2010 18:21:20 GMT

status new → closed
resolution → fixed

Fixed in trunka and release branches