From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263309AbVGALfA (ORCPT ); Fri, 1 Jul 2005 07:35:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263227AbVGALfA (ORCPT ); Fri, 1 Jul 2005 07:35:00 -0400 Received: from frankvm.xs4all.nl ([80.126.170.174]:54710 "EHLO janus.localdomain") by vger.kernel.org with ESMTP id S263306AbVGALeK (ORCPT ); Fri, 1 Jul 2005 07:34:10 -0400 Date: Fri, 1 Jul 2005 13:34:08 +0200 From: Frank van Maarseveen To: Miklos Szeredi Cc: frankvm@frankvm.com, akpm@osdl.org, aia21@cam.ac.uk, arjan@infradead.org, linux-kernel@vger.kernel.org Subject: Re: FUSE merging? Message-ID: <20050701113408.GA5218@janus> References: <20050630022752.079155ef.akpm@osdl.org> <1120125606.3181.32.camel@laptopd505.fenrus.org> <1120126804.3181.34.camel@laptopd505.fenrus.org> <1120129996.5434.1.camel@imp.csi.cam.ac.uk> <20050630124622.7c041c0b.akpm@osdl.org> <20050701093627.GB4317@janus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Subliminal-Message: Use Linux! Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 01, 2005 at 12:45:22PM +0200, Miklos Szeredi wrote: > > > > > > Here's a description of a theoretical DoS scenario: > > > > > > http://marc.theaimsgroup.com/?l=linux-fsdevel&m=111522019516694&w=2 > > > > So the open() hangs indefinately. but what if blackhat tries to install > > a package from a no longer existing server on /net or via NFS? > > > > A user supplied pathname is not to be trusted by any setuid (or full > > root) program. > > If /net won't detect a dead server within a timeout, I think it can be > considered broken. > > > Another example: I'm not sure if there are still /dev/tty devices which > > may block indefinately upon open() but: > > > > - I have yet to see a setuid program which always uses O_NONBLOCK > > when opening user supplied pathnames. > > - one cannot stat() and then open() because that gives a race. > > Is "being already broken" an excuse for preventing future breakage, > when these are fixed? All this breakage points into the same direction: A user supplied pathname is not to be trusted by any setuid (or full root) program. -- Frank