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
