From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wright Subject: Re: DoS with POSIX file locks? Date: Tue, 21 Mar 2006 11:16:05 -0800 Message-ID: <20060321191605.GB15997@sorel.sous-sol.org> References: <20060320121107.GE8980@parisc-linux.org> <20060320123950.GF8980@parisc-linux.org> <20060320153202.GH8980@parisc-linux.org> <1142878975.7991.13.camel@lade.trondhjem.org> <1142962083.7987.37.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: trond.myklebust@fys.uio.no, chrisw@sous-sol.org, matthew@wil.cx, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: Received: from 216-99-217-87.dsl.aracnet.com ([216.99.217.87]:36480 "EHLO sorel.sous-sol.org") by vger.kernel.org with ESMTP id S965073AbWCUTQL (ORCPT ); Tue, 21 Mar 2006 14:16:11 -0500 To: Miklos Szeredi Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org * Miklos Szeredi (miklos@szeredi.hu) wrote: > > > Apps using LinuxThreads seem to be candidates: > > > > > > According to POSIX 1003.1c, a successful `exec*' in one of the > > > threads should automatically terminate all other threads in the > > > program. This behavior is not yet implemented in LinuxThreads. > > > Calling `pthread_kill_other_threads_np' before `exec*' achieves > > > much of the same behavior, except that if `exec*' ultimately > > > fails, then all other threads are already killed. > > > > > > steal_locks() was probably added as a workaround for this case, no? > > > > Possibly, but LinuxThreads were never really POSIX thread compliant > > anyway. Anyhow, the problem isn't really LinuxThreads, it is rather that > > the existence of the standalone CLONE_FILES flag allows you to do a lot > > of weird inheritance crap with 'posix locks' that the POSIX standards > > committees never even had to consider. > > Yes. The execve-with-multiple-threads/posix-locks interaction is not > documented for LinuxThreads but removing steal_locks() makes that > implementation slighly differently incompatible to POSIX. Some > application _might_ be relying on the current behavior. > > It's just a question of how much confidence do we have, that no app > will break if steal_locks() is removed. This function was added by > Chris Wright on 2003-12-29 (Cset 1.1371.111.3): > > Add steal_locks helper for use in conjunction with unshare_files to > make sure POSIX file lock semantics aren't broken due to > unshare_files. > > Chris, do you remember if this was due to some concrete breakage or > just a preemtive measure? Concrete breakage. Something like: clone(CLONE_FILES) /* in child */ lock execve lock w/out the kludge[1], the lock fails. I should have a test program about that I wrote to test this, although it was originally triggered via some LTP or LSB type of test (don't recall which). thanks, -chris [1] happy to see it go. i concur with Trond, there's no sane way to get rid of it w/out formalizing CLONE_FILES and locks on exec