From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 11:59:12 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A561106566C; Thu, 10 Dec 2009 11:59:12 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 711748FC08; Thu, 10 Dec 2009 11:59:12 +0000 (UTC) Received: from [192.168.2.102] (host86-146-40-97.range86-146.btcentralplus.com [86.146.40.97]) by cyrus.watson.org (Postfix) with ESMTPSA id 8F1E146B2D; Thu, 10 Dec 2009 06:59:11 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <9bbcef730912100159s49704c18o1225d060c422b273@mail.gmail.com> Date: Thu, 10 Dec 2009 11:59:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <42E1ACF8-08AA-46D6-9BF9-65B543059C8F@freebsd.org> References: <20091130142950.GA86528@logik.internal.network> <20091130150127.GA82188@logik.internal.network> <237c27100912010722g2f6c4647ga82370284bc26e20@mail.gmail.com> <9bbcef730912100159s49704c18o1225d060c422b273@mail.gmail.com> To: Ivan Voras X-Mailer: Apple Mail (2.1077) Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt Subject: Re: UNIX domain sockets on nullfs still broken? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 11:59:12 -0000 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=