From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [patch 0/8] mount ownership and unprivileged mount syscall (v4) Date: Tue, 24 Apr 2007 19:04:36 -0600 Message-ID: References: <20070420102532.385211890@szeredi.hu> <20070425000414.GH14086@petra.dvoda.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Miklos Szeredi , akpm@linux-foundation.org, serue@us.ibm.com, viro@ftp.linux.org.uk, linuxram@us.ibm.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, containers@lists.osdl.org To: Karel Zak Return-path: Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:57141 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754673AbXDYBGq (ORCPT ); Tue, 24 Apr 2007 21:06:46 -0400 In-Reply-To: <20070425000414.GH14086@petra.dvoda.cz> (Karel Zak's message of "Wed, 25 Apr 2007 02:04:14 +0200") Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Karel Zak writes: > On Fri, Apr 20, 2007 at 12:25:32PM +0200, Miklos Szeredi wrote: >> The following extra security measures are taken for unprivileged >> mounts: >> >> - usermounts are limited by a sysctl tunable >> - force "nosuid,nodev" mount options on the created mount > > The original userspace "user=" solution also implies the "noexec" > option by default (you can override the default by "exec" option). > > It means the kernel based solution is not fully compatible ;-( Why noexec? Either it was a silly or arbitrary decision, or our kernel design may be incomplete. Now I can see not wanting to support executables if you are locking down a system. The classic don't execute a program from a CD just because the CD was stuck in the drive problem. So I can see how executing code from an untrusted source could prevent exploitation of other problems, and we certainly don't want to do it automatically. Eric