On Fri, 25 Jun 2021 20:18:39 -0700
James Gritton <ja...@freebsd.org> wrote:
> 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).
>
Hi Jamie,
I *finally* found the time to write the bug reports:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257554
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257555
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257556
I took the liberty to assign them to you.
Best,
Michael
--
Michael Gmelin