Date: Fri, 25 Jun 2021 20:18:39 -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: <8d9eb169d7b0072cd6f7ff00f5757842@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: > Another problem caused by the lack of jail ownership is that access > semantics are a bit strange. E.g., a jail based on / can easily list > (and remove) all memory allocations in the system, while for other > jails > it depends. They can stat their own allocations like in: > > # posixshmcontrol stat /xyz > output as expected... > > But not list them: > > # posixshmcontrol ls > posixshmcontrol: cannot get kern.ipc.posix_shm_list length: > Operation not permitted > > Probably related to matching the path of the allocation, I didn't look > into the code. That's just a case of the sysctl not being marked as jail-safe. Looking at the code, it's clear that it needs to be altered when called from within a jail, but preventing it is definitely not the right thing. > but having something automatic in the OS would be nice. Or being > able to run `posixshmcontrol -j shmtest ls`. Seems like this would be > quite some effort though to get it right - also in terms of who can > access what - right now, it's simply based on the path, which also > gives > a lot of flexibility. Since access to the shared memory segments themselves is only on file permissions and pathnames, just making a "posixshmcontrol -j" also rely on pathnames actually makes sense. Put this into a bug report, and I'll take a closer look. Probably two different bugs for different issues (listing and automatic removal). - Jamie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8d9eb169d7b0072cd6f7ff00f5757842>