Modify

Opened 7 years ago

Closed 7 years ago

#4694 closed Bugs (fixed)

Jailed FreeBSD needs BOOST_INTERPROCESS_FILESYSTEM_BASED_POSIX_SHARED_MEMORY

Reported by: Jim Bell <jim@…> Owned by: Ion Gaztañaga
Milestone: To Be Determined Component: interprocess
Version: Boost 1.44.0 Severity: Problem
Keywords: FreeBSD jail Cc:

Description

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?

Attachments (0)

Change History (7)

comment:1 Changed 7 years ago by Jim Bell <jim@…>

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

comment:2 Changed 7 years ago by Jim Bell <jim@…>

sysctl shows:

security.jail.sysvipc_allowed: 0

comment:3 Changed 7 years ago by 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)?

comment:4 Changed 7 years ago by 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.

comment:5 Changed 7 years ago by 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.

comment:6 Changed 7 years ago by 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

comment:7 Changed 7 years ago by Ion Gaztañaga

Resolution: fixed
Status: newclosed

Fixed in trunka and release branches

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Ion Gaztañaga.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.