Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Jun 2021 20:08:31 -0700
From:      James Gritton <jamie@freebsd.org>
To:        jail@freebsd.org
Cc:        Michael Gmelin <freebsd@grem.de>
Subject:   Re: POSIX shared memory and dying jails
Message-ID:  <75475234c76c97c67a8bd2525669c650@freebsd.org>
In-Reply-To: <20210625185859.40fead46@bsd64.grem.de>
References:  <20210625164100.73c71055@bsd64.grem.de> <03809b2655a40134dd802386afa6be7d@freebsd.org> <20210625185859.40fead46@bsd64.grem.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-06-25 09:58, Michael Gmelin wrote:
> On Fri, 25 Jun 2021 09:19:05 -0700
> James Gritton <jamie@freebsd.org> wrote:
> 
>> On 2021-06-25 07:41, Michael Gmelin wrote:
>> > It seems like non-anonymous POSIX shared memory is not freed
>> > automatically when a jail is removed and keeps it in a dying state,
>> > until the shared memory segment is deleted manually.
>> >
>> > 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
>> >
>> > I wonder if it wouldn't make sense to always remove POSIX shared
>> > memory created by a jail automatically when it's removed.
>> 
>> That does seem reasonable, though it would take some bookkeeping to do
>> right.  There is currently no concrete idea of a jail's ownership of a
>> POSIX shm object, as it uses only uid and gid for access permissions,
>> same as files.  The tie to the jail is in the underlying vm_object,
>> which holds a cred that references the jail - that seems to be what's
>> keeping the jail from going away.
> 
> Interesting - I was wondering how that worked, thanks. Would there by a
> way to cut that tie somehow (for use cases that deliberately want to
> leave the shared memory segment behind)?

It might be possible to change vm_object's cred to one that has the
same uid/gid but is outside of the jail.  The big argument against
that is that I don't know enough about the VM subsystem to go poking
about there lightly.

 From the user perspective, you can keep such objects with a little
planning ahead: always create them outside of the jail, though using
the jail's path in the name (which is how a non-jailed process would
refer to it anyway).  Then jailed processes can access the shared
memory, but won't own it.

- Jamie



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75475234c76c97c67a8bd2525669c650>