Date: Thu, 10 Dec 2009 11:59:09 +0000 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt <linda.messerschmidt@gmail.com> Subject: Re: UNIX domain sockets on nullfs still broken? Message-ID: <42E1ACF8-08AA-46D6-9BF9-65B543059C8F@freebsd.org> In-Reply-To: <9bbcef730912100159s49704c18o1225d060c422b273@mail.gmail.com> References: <20091130142950.GA86528@logik.internal.network> <hf0lle$5mk$1@ger.gmane.org> <20091130150127.GA82188@logik.internal.network> <hf0ngp$cpb$1@ger.gmane.org> <237c27100912010722g2f6c4647ga82370284bc26e20@mail.gmail.com> <alpine.BSF.2.00.0912100943450.23303@fledge.watson.org> <9bbcef730912100159s49704c18o1225d060c422b273@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10 Dec 2009, at 09:59, Ivan Voras wrote: > You have a point there. I was actually thinking more of sysvshm - > which doesn't have anything to do with any of the issues here - but > has some of the same properties (and is also used by databases - e.g. > postgresql, which I'm using daily so it sort of cross-linked). The > reason I'd like the nullfs barrier kept is that it (like shm) is used > for IPC, and in this case, IPC across different jails (though a file > system itself also be used so...). It's not a big issue - I'll also > accept that it's the operator's fault if he doesn't know sharing file > systems will also share sockets and fifos on it... Yeah, what this really comes down to is IPC namespaces. We have a lot, = and they have different properties, unfortunately, leading to different = interactions with Jail, which is largely about namespace subsetting. = Very little is about IPC "between" jails, but rather, whether the IPC = namespace supported easy subsetting/virtualization. In the new vimage = world order, it should now be "easy" to virtualize all of the remaining = IPC namespaces (small matter of code). Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42E1ACF8-08AA-46D6-9BF9-65B543059C8F>