Modify

Ticket #4694 (closed Bugs: fixed)

Opened 4 years ago

Last modified 4 years ago

Jailed FreeBSD needs BOOST_INTERPROCESS_FILESYSTEM_BASED_POSIX_SHARED_MEMORY

Reported by: Jim Bell <jim@…> Owned by: igaztanaga
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

Change History

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

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

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

sysctl shows:

security.jail.sysvipc_allowed: 0

comment:3 Changed 4 years ago by igaztanaga

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 4 years ago by igaztanaga

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 4 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 4 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 4 years ago by igaztanaga

  • Status changed from new to closed
  • Resolution set to fixed

Fixed in trunka and release branches

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


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

 
Note: See TracTickets for help on using tickets.