Date: Wed, 29 Apr 2026 12:56:53 -0700 From: James Gritton <jamie@freebsd.org> To: Freebsd Hackers <freebsd-hackers@freebsd.org> Cc: Milan Obuch <freebsd-hackers@dino.sk> Subject: Re: SYSVIPC and jails Message-ID: <872527688056fd21b6ece46fc89944ca@freebsd.org> In-Reply-To: <20260429090547.16709362.28181704.71119016@dino.sk>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?872527688056fd21b6ece46fc89944ca>