Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: plan9 semantics on Linux - mount namespaces
From:   Enrico Weigelt <lkml@metux.net>
To:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <0f058286-a432-379b-f559-f2fe713807ab@metux.net>
Cc:     Linux Containers <containers@lists.linux-foundation.org>
Organization: metux IT consult
Message-ID: <5633d335-3926-d98f-d6d7-948b1e2a0b2c@metux.net>
Date:   Tue, 13 Feb 2018 22:19:48 +0000
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <0f058286-a432-379b-f559-f2fe713807ab@metux.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 13.02.2018 22:12, Enrico Weigelt wrote:

CC @containers@lists.linux-foundation.org

> Hi folks,
> 
> 
> I'm currently trying to implement plan9 semantics on Linux and
> yet sorting out how to do the mount namespace handling.
> 
> On plan9, any unprivileged process can create its own namespace
> and mount/bind at will, while on Linux this requires CAP_SYS_ADMIN.
> 
> What is the reason for not allowing arbitrary users to create their
> own private mount namespace ? What could go wrong here ?
> 
> IMHO, we could allow mount/bind under the following conditions:
> 
> * the process is in a private mount namespace
> * no suid-flag is honored (either force all mounts to nosuid or
>    completely mask it out)
> * only certain whitelisted filesystems allowed (eg. 9P and FUSE)
> 
> Maybe that all could be enabled by a new capability.
> 
> 
> any suggestions ?
> 
> 
> --mtx
> 


-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287