to:freebsd-hackers+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-hackers+unsubscribe@freebsd.org>
Sender: owner-freebsd-hackers@FreeBSD.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-1.23 / 15.00];
	NEURAL_SPAM_LONG(0.99)[0.993];
	NEURAL_HAM_MEDIUM(-0.99)[-0.989];
	NEURAL_HAM_SHORT(-0.94)[-0.935];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_COUNT_ONE(0.00)[1];
	ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_NONE(0.00)[];
	DMARC_NA(0.00)[dino.sk];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[]
X-Spamd-Bar: -
X-Rspamd-Queue-Id: 4g5WD1689Cz3s5l

On Wed, 29 Apr 2026 12:56:53 -0700
James Gritton <jamie@freebsd.org> wrote:

> 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).

It did not work that way in old 'just on and off' time... when
allow.sysvipc is on, both id and key are the same in base and jail, no
difference. Actually, I see no rationale why should key space be
separated in case of mutual visibility. Do you? I'd like to know more.

> 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.

... which is what I'd like to use.

> 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.

So it is possible to get documented behavior for real? That would be
great.

> 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.

I'll try to do it and let you know, just a bit later I am afraid :)

Regards,
Milan