From nobody Sat Jun 26 03:18:39 2021 X-Original-To: jail@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0F6B311E3EDF for ; Sat, 26 Jun 2021 03:18:41 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [199.192.165.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GBfGS6K56z4kQP for ; Sat, 26 Jun 2021 03:18:40 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org ([127.0.0.131]) (authenticated bits=0) by gritton.org (8.15.2/8.15.2) with ESMTPA id 15Q3Id0n031562; Fri, 25 Jun 2021 20:18:39 -0700 (PDT) (envelope-from jamie@freebsd.org) List-Id: Discussion about FreeBSD jail(8) List-Archive: https://lists.freebsd.org/archives/freebsd-jail List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-jail@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 Jun 2021 20:18:39 -0700 From: James Gritton To: jail@freebsd.org Cc: Michael Gmelin Subject: Re: POSIX shared memory and dying jails In-Reply-To: <20210625185859.40fead46@bsd64.grem.de> References: <20210625164100.73c71055@bsd64.grem.de> <03809b2655a40134dd802386afa6be7d@freebsd.org> <20210625185859.40fead46@bsd64.grem.de> User-Agent: Roundcube Webmail/1.4.1 Message-ID: <8d9eb169d7b0072cd6f7ff00f5757842@freebsd.org> X-Sender: jamie@freebsd.org X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (gritton.org [127.0.0.131]); Fri, 25 Jun 2021 20:18:39 -0700 (PDT) X-Rspamd-Queue-Id: 4GBfGS6K56z4kQP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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