Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261153AbVD3I35 (ORCPT ); Sat, 30 Apr 2005 04:29:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261155AbVD3I34 (ORCPT ); Sat, 30 Apr 2005 04:29:56 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:10926 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S261153AbVD3I3y (ORCPT ); Sat, 30 Apr 2005 04:29:54 -0400 Date: Sat, 30 Apr 2005 09:29:52 +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: <20050430082952.GA23253@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> 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: 1617 Lines: 47 On Sat, Apr 30, 2005 at 10:14:07AM +0200, Miklos Szeredi wrote: > > Except that we don't have the concept of a mount owner at the VFS level > > right now, because everyone is adding stupid suid wrapper hacks instead > > of trying to fix the problems for real. > > Having a mount owner is not a problem. Having a good policy for > accepting mounts is rather more so, according to some: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=107705608603071&w=2 > > Just a little taste of what that policy would involve: > > - global limit on user mounts I don't think we need that one. > - possibly per user limit on mounts Makes sense as an ulimit, that way the sysadmin can easily disable the user mount feature aswell. > - acceptable mountpoints (unlimited writablity is probably a good minimum) Yupp. > - acceptable mount options (nosuid, nodev are obviously not) noexecis a bit too much, so the above look good. > - filesystems "safe" to mount by users what filesystem do you think is unsafe? - 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) - block-based filesystems should be safe as long as the mounter has access to the underlying block device - network/userspace filesystems should be fine aswell - 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/