Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261947AbVEKJAc (ORCPT ); Wed, 11 May 2005 05:00:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261940AbVEKJAb (ORCPT ); Wed, 11 May 2005 05:00:31 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:64426 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S261933AbVEKI7W (ORCPT ); Wed, 11 May 2005 04:59:22 -0400 Date: Wed, 11 May 2005 09:59:21 +0100 From: Christoph Hellwig To: Miklos Szeredi Cc: hch@infradead.org, 7eggert@gmx.de, smfrench@austin.rr.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread Message-ID: <20050511085921.GB24841@infradead.org> Mail-Followup-To: Christoph Hellwig , Miklos Szeredi , 7eggert@gmx.de, smfrench@austin.rr.com, linux-kernel@vger.kernel.org References: <3YLdQ-4vS-15@gated-at.bofh.it> <20050430073238.GA22673@infradead.org> <20050430082952.GA23253@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1770 Lines: 42 On Sat, Apr 30, 2005 at 11:22:48AM +0200, Miklos Szeredi wrote: > > - virtual filesystems exporting kernel data are obviously safe as > > they enforce permissions no matter who mounted them. (actually we'd > > need to check for some odd mount options) > > Maybe sysadmin doesn't want to let users see /sys for example. How > would you disable it if users can mount it themselfes? OK, you can > disable user mounts completely, but that's probably not fine grained > enough for some. the sysadmin shouldn't do that. sysfs is needed for proper operation in a modern system and there's nothing to hid in there. > > - block-based filesystems should be safe as long as the mounter has > > access to the underlying block device > > Not true if user controls the baking device (e.g. loopback). I didn't say we should make using the loopback driver a non-privilegued operation. > Most > block based filesystems are probably unsafe at the moment, because not > enough consistency checking is done at runtime. Are things like > non-cyclic directory graphs ensured by all filesystems? My guess is > not. See also Linus' comment about the state of the iso9660 > filesystem: > > http://lwn.net/Articles/128744/ It just mean that a) the system admin should be careful what drivers are loaded and b) we need to audit block based filesystems better. Note that in many current distributions users can mount iso9660 filesystems through user mount hacks already. Accessible to everyone and in the global namespace. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/