Bug 257555 - POSIX shared memory: Cleanup non-anonymous allocations on jail exit
Summary: POSIX shared memory: Cleanup non-anonymous allocations on jail exit
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 13.0-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: Jamie Gritton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-08-02 10:03 UTC by Michael Gmelin
Modified: 2021-08-06 21:39 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Gmelin freebsd_committer 2021-08-02 10:03:12 UTC
When a jail exits, POSIX shared memory segments allocated by it
will stay around, unless removed from within the jail in an
orderly fashion.

As a side effect, this keeps the jail in a dying state forever/until
non-anonymous shared memory segments are removed.

Basic example:
See below for the most basic example:

    [root@jailhost ~]# jail -c path=/ command=/bin/sh
    # posixshmcontrol create /removeme
    # exit
    [root@jailhost ~]# jls -dv -j shmtest dying
    true

So at this point, the jail is stuck in a dying state.

Checking POSIX shared memory segments shows the shared memory segment
which is stopping the jail from crossing the Styx:

    [root@jailhost ~]# posixshmcontrol list
    MODE            OWNER   GROUP   SIZE    PATH
    rw-------       root    wheel   0       /removeme

After removing the shared memory segment manually...

    [root@jailhost ~]# posixshmcontrol rm /removeme

the jail passes away peacefully:

    [root@jailhost ~]#  jls -dv -j shmtest dying
    jls: jail "shmtest" not found

In our discussion on the jails mailing list[0] it was suggested
that it might be the easiest and most straightforward way to
solve this would be to free shared memory segments based on their
path, as access is controlled by the path too. The only questions is
how to handle multiple jails using the same jailroot in this case
(and if this is legitimate/important enough use case to bother).

[0]https://lists.freebsd.org/archives/freebsd-jail/2021-June/000029.html