From nobody Wed Apr 29 07:05:47 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 4g57cl2Kjjz6b39N for ; Wed, 29 Apr 2026 07:05:59 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (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 4g57cj2WQKz3Ps1 for ; Wed, 29 Apr 2026 07:05:57 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk Received: from dino.sk ([84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by cm0.netlabit.sk with ESMTPSA id 00000000004BF0CD.0000000069F1ADCC.00006D0F; Wed, 29 Apr 2026 09:05:48 +0200 Date: Wed, 29 Apr 2026 09:05:47 +0200 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: SYSVIPC and jails Message-ID: <20260429090547.16709362.28181704.71119016@dino.sk> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-1.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.70)[0.699]; NEURAL_HAM_SHORT(-0.70)[-0.698]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(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)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4g57cj2WQKz3Ps1 Hi, I am trying to move some old data collecting system to recent OS. Jails (with vnet in old system, both non-vnet and vnet ones in newer in order to do some division of tasks for better maintainability) and shared memory is in use, allowing the jails to share some status data, possibly fast changing. 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. This leads to No such file or directory error when calling shmget to attach existing shared memory segment. If I use zero value for shmkey in shmget call, fail moves to shmat call, and error is Permission denied even in the jail where this segment was created. 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. What changed I am missing? How should I achieve desired behavior? I am out of ideas. By the way, I am using kernel modules, but all required are loaded - this approach works if no inter jail shared memory segment visibility is required. Regards, Milan