Re: POSIX shared memory and dying jails

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