From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Ayuso Subject: Re: [PATCH iptables] iptables: use IPC semaphore instead of abstract unix sockets Date: Mon, 19 Jan 2015 14:21:43 +0100 Message-ID: <20150119132143.GA4545@salvia> References: <1421615616-23053-1-git-send-email-pablo@netfilter.org> <20150119122410.GA4206@salvia> <20150119125118.GK17886@acer.localdomain> <20150119130024.GA4410@salvia> <20150119130634.GA4425@salvia> <20150119130833.GA8818@acer.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Engelhardt , netfilter-devel@vger.kernel.org, kernel@linuxace.com, lennart@poettering.net To: Patrick McHardy Return-path: Received: from mail.us.es ([193.147.175.20]:35616 "EHLO mail.us.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751680AbbASNTQ (ORCPT ); Mon, 19 Jan 2015 08:19:16 -0500 Content-Disposition: inline In-Reply-To: <20150119130833.GA8818@acer.localdomain> Sender: netfilter-devel-owner@vger.kernel.org List-ID: On Mon, Jan 19, 2015 at 01:08:33PM +0000, Patrick McHardy wrote: > On 19.01, Pablo Neira Ayuso wrote: > > On Mon, Jan 19, 2015 at 02:00:24PM +0100, Pablo Neira Ayuso wrote: > > > On Mon, Jan 19, 2015 at 12:51:19PM +0000, Patrick McHardy wrote: > > > > On 19.01, Pablo Neira Ayuso wrote: > > > > > "This patch introduces a semaphore that is identified by the path to > > > > > the iptables binary, it also relies on SEM_UNDO so the kernel performs > > > > > the up() operation at process exit to avoid races with signals. This > > > > > also avoids file locks that require a writable filesystem." > > > > > > > > Is it wise to use the path? Not that its very common, but multiple > > > > binaries would still race. Any reason you chose not to use something > > > > globally unique? > > > > > > What kind of race are you worrying about? > > > > Oh, I get it. Several different iptables binaries located in different > > paths. This patch cannot address that situation, we can select a > > hardcoded key but we may conflict with other applications. > > Sure, but that risk also exists with using the path. > > > Regarding the use of posix semaphores, there is no SEM_UNDO feature, > > so we can have problem if this receives a kill signal or it > > abort/crash somewhere in the code. > > > > I think the best solution is to use to flock() as others do but then > > we need a writable filesystem() which is what Phil was trying to skip. > > > > Question is if we should really care. I mean, this locking solution > > was introduced as a workaround given we couldn't solve this in the > > kernel. > > I think your patch is fine, just wanted to point out that we might > want to choose a hardcoded name. I think the risk of clashes with > other applications is absolutely minimal. Makes sense to me. This is how ftok() calculates the key based on the path: key = ((st.st_ino & 0xffff) | ((st.st_dev & 0xff) << 16) | ((proj_id & 0xff) << 24)); We can a select a magic number for that key, any candidates? Thanks!