From nobody Wed Apr 29 19:56:53 2026 X-Original-To: freebsd-hackers@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 4g5SkG47G6z6bptf for ; Wed, 29 Apr 2026 19:56:54 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g5SkG3bTxz3S1Z; Wed, 29 Apr 2026 19:56:54 +0000 (UTC) (envelope-from jamie@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1777492614; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nWS4VdrXhAgkDlaT4I3gigb4EuMVX/7DCsiRtLD+dMo=; b=VfthfBDi72s23IK2C8MmCiGgFMyVO9sYVqXUIO9SA4GbYbckf4iwUNDlCAXfrFXxA98RnY Z9QyN0pH3osyW59SmUH2Xek8ADBDCCeQSCa8Wioy1oiq1ckyD4R4Rj0jsaH27Nycs9fC47 EhVBL7tznkqFN/YWU5WyMLGjvXCUVSQYdsgd6+I1lOQpIu5JdK+RLtfmb7B/BR5k+23wjH iADjwCnIrzSPi9QdYGZ5tanYEmxuCF8iViefhfI2efVm0NaOUByxDg/m7n3qsMd/cXqO3f 17xaKXueYiTBabzjvA+6SMRpKTcB4kbno5cV27ivsn6TcERd8YFpfPGRj50VpA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1777492614; a=rsa-sha256; cv=none; b=I4a6YgE0QsPrKL8XsbpbQKPrRyPcyf9KT+kBThpexnOftKTv4AVKPPVkPkUMdoFo0zAd4+ yw4OLB5N6kJXopDUZonH9OqQDu7dSpBRNt3+jZO9aqVFSUlkszChm4gV4w0/TQKpCFe4q1 sBUXaauoPQjYd/kWpCWKYgrWFeqKHRd37dBzZRrZRLxQCAEeYxZj3k7XlIY15cYkt7vSKv cOY4ZvyZcgYGIrCNA+Rayuzkar72BQzbHoEcUXDjEVQXk/yvX1Nab4/YFHF3FabUBZMWK1 3e443cwxlFV6+4xDX1kGHkR8JJU9ZOSHu5pFHpwNy64o9vTdRZSB+iZT3oUTtg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1777492614; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nWS4VdrXhAgkDlaT4I3gigb4EuMVX/7DCsiRtLD+dMo=; b=mTxSkwf0ucbG9CzyzGfEvp+FqEitwDulAmYpLvMuuY67bZWhwCVk9VEBEbEoV8kDemmtGM qXmdblAApm7ykBefj6kdYqyD0vWkgMhaybliuX2U1MZVPP7QadCcQLGCjrfdEtQq1YXhco nkY4wbWYdcZ0OxcGGcfjDmAp/B3mVsJSGNJ3kzNmaFx6+Jkh3+Aq59ERLH4g4QEkzjSq7o +1crOXHX4NFDBR1WL5DXbVHGmk3YEIwbR9TUSm7J6KbfMgDZvHCHo/AmmdowHvFV2oMBAr lllr2+ITagQqgXMQVbkh86Y21S5HOILpfomfgynca5CPl30SkdlbKFYhS9tKuQ== Received: from m2.gritton.org (gritton.org [67.43.236.212]) (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) (Authenticated sender: jamie) by smtp.freebsd.org (Postfix) with ESMTPSA id 4g5SkG2fdVz3Xx; Wed, 29 Apr 2026 19:56:54 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (localgritton [127.0.0.212]) by m2.gritton.org (Postfix) with ESMTPSA id 36F5A7105B; Wed, 29 Apr 2026 12:56:53 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Date: Wed, 29 Apr 2026 12:56:53 -0700 From: James Gritton To: Freebsd Hackers Cc: Milan Obuch Subject: Re: SYSVIPC and jails In-Reply-To: <20260429090547.16709362.28181704.71119016@dino.sk> References: <20260429090547.16709362.28181704.71119016@dino.sk> Message-ID: <872527688056fd21b6ece46fc89944ca@freebsd.org> X-Sender: jamie@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2026-04-29 00:05, Milan Obuch wrote: > Original system is over 10 years old, based on FreeBSD 9.3, basically > no longer maintainable, and it started to show some problems. Jail here > was created with simple command > > jail -c name=xxx vnet persist allow.sysvipc > > and everything just works. In base system a shared memory segment is > created, filled with some data, subsequently it is used in both base > system and jail. > > I can't get this behavior with FreeBSD 14.3 (I tested a bit with 15.0 > as > well, not fully). I know allow.sysvipc should be replaced with sysvshm > and, additionally if usefull, sysvmsg and sysvsem, but that's not an > issue. With 'jls -vs' I see following properties > > sysvmsg=inherit > sysvsem=inherit > sysvshm=inherit > allow.sysvipc > > set, so, according to 'man jail' it should work. It does not, however - > when using non-null integer for shmkey in shmget call, I see that > number in 'ipcs -a' output in jail where this segment is created, but > zero in another jail. Yes, according to the docs it should work, and no it actually doesn't. There's a historical quirk at work here, between the way allow.sysvipc was set up, and the design when the sysvmsg/etc parameters were added: allow.sysvipc was only on or off, an on meant that jails could see each others' SYSV IPC objects, but kept their own key spaces (so you see zero as the key when you example other jails' objects). You could interact beytween jails, but only if you had some way of communicating the id apart from the normal method of using the key. sysvxxx=new gives the jail its own namespace, with both keys and ids unique to the jail. sysvxxx=inherit uses the parent's namespace for both keys and ids, as if you were in the same jail. At least that's how it's supposed to work, and how it's documented to work. But in reality, sysvxxx=inherit is exactly the same as allow.sysvipc. ID space is shared, but each jail has its own key space. File a bug report for this, and I'll work on getting it fixed. Hopefully, no one is relying on the weird hybrid behavior, but just in case, I can leave it for the otherwise-obsolete allow.sysvipc parameter. - Jamie PS > Looking into sysctl for possible hint, I found two objects with sysvipc > in their names, with jail in their tree, additionaly: > > security.jail.param.allow.sysvipc > security.jail.sysvipc_allowed > > I am able to set the latter to 1, but not the former, executing > > sysctl security.jail.param.allow.sysvipc=1 > > does not change the value, while executing > > sysctl security.jail.sysvipc_allowed=1 > > changes the object's value from 0 to 1. Even after this change, shared > memory segment is not shared among jails. security.jail.param.* never change anything. They're just how the jail system makes userspace aware of what parameters exist and how they're coded. security.jail.sysvipc.allowed (and a host of other such sysctls) are a relic of the old jail system, where almost all options were global, and are now default value of per-jail parameters.