From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932091AbZCPW7y (ORCPT ); Mon, 16 Mar 2009 18:59:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757759AbZCPW7o (ORCPT ); Mon, 16 Mar 2009 18:59:44 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:51555 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755452AbZCPW7n (ORCPT ); Mon, 16 Mar 2009 18:59:43 -0400 Date: Mon, 16 Mar 2009 17:59:40 -0500 From: "Serge E. Hallyn" To: "J. Bruce Fields" Cc: Igor Zhbanov , Michael Kerrisk , linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, neilb@suse.de, Trond.Myklebust@netapp.com, David Howells , James Morris , linux-security-module@vger.kernel.org, Miklos Szeredi , "Eric W. Biederman" Subject: Re: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK? Message-ID: <20090316225940.GA15522@us.ibm.com> References: <20090311232356.GP13540@fieldses.org> <20090312161047.GA15209@us.ibm.com> <517f3f820903121321sf6d2014q8165b925d5d44db7@mail.gmail.com> <20090313175848.GB27891@fieldses.org> <20090316163611.GB10959@fieldses.org> <20090316170433.GA2996@us.ibm.com> <20090316225424.GD17738@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090316225424.GD17738@fieldses.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting J. Bruce Fields (bfields@fieldses.org): > On Mon, Mar 16, 2009 at 12:04:33PM -0500, Serge E. Hallyn wrote: > > Quoting J. Bruce Fields (bfields@fieldses.org): > > > If filesystem permissions similarly never affected the ability to create > > > device nodes, that might also be an argument against including > > > CAP_MKNOD, but it would be interesting to know the pre-capabilities > > > behavior of a uid 0 process with fsuid non-0. > > > > The sentiment rings true, but again since before capabilities, privilege > > was fully tied to the userid, the question doesn't make sense. Either > > you had uid 0 and could mknod, or you didn't and couldn't. And that is > > the behavior which we unfortunately have to emulate when > > !issecure(SECURE_NOROOT|SECURE_NOSUIDFIXUP). > > The historical behavior of setfsuid() is still interesting, though. > >From a quick glance at Debian's code for the (long-neglected) userspace > nfsd server, it looks like it depends on setfsuid() and the kernel to > enforce permissions for operations (including mknod). Might be Sorry, do you mean that it would expect setfsuid(0) to allow a task to do mknod, and setfsuid(500) to disable it? Actually I guess for mknod, that is the question we can answer with the a 2.1.x tree: which uid did mknod check? Ah, answer is... fsuid! > interesting to confirm whether it has the same problem, and if so, > whether that was a problem introduced with some capability changes or > whether it always existed. > > --b.