Received: by 10.223.185.116 with SMTP id b49csp1045433wrg; Fri, 16 Feb 2018 11:24:10 -0800 (PST) X-Google-Smtp-Source: AH8x227MP9HVpdD0EZVJAJ6IOc+JINHg/CHhmDRnV+Dqc6io7jezt7PbLF/S5YjFVPxFHtQi2qJw X-Received: by 10.99.39.1 with SMTP id n1mr5890189pgn.155.1518809050814; Fri, 16 Feb 2018 11:24:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518809050; cv=none; d=google.com; s=arc-20160816; b=R+X+1ml9yWJXI/B7V7Fe/Y7nwwXP0ExKHnqPN9CSFfoPAzBu6vcQXUDROi6XZH4xZw LwyuZ7tCdi8HTvzaKvx3wczVYCI6DrAoEQVhRy4Fel4cUqDq8ptM9PHKBcf/P4l9il4D xDan7cFVcychGTjhYAb0kEDtBd1KqV6PyCGET5M+qvFgcr0/hckuewcy9vUxS+FdV4Ye zc+TB4rSEasleZ3mNmSH5jSwCkFbRee0yG19LttqHuE5pUROwtDlflfSXp8YNsHowCzz OCYPTQ5jy8wgrNicsG1S8a7pALHnKHCeOs46Vc4d+wiQ+gNyFDqgEGRpv7aLNEJ6t67A Wmtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:content-transfer-encoding :mime-version:user-agent:message-id:in-reply-to:date:references:cc :to:from:arc-authentication-results; bh=cJynGFa7J61ZlDjhxBOAvmg1LSqA6HibDZq7t5ISirk=; b=AalUI6r3ibXjEDI4drix/18VsNgYuth2cnMTBr/zMAdumKxataOH8p5oKmR4OxREgw HG1YT1xXewHTJNz8Cf9Yy+KwKO8+y1gwIZepV4Z5m68MFA3AcnC4l6eoSMs77WOJ/K5j 4JU2VEKpaYTQxMBSj6CjgZJKBAWqdf28FYWkVOXMMzEvg5Rjfe4tR1OhJQfbBuAHXBTN yke7y7Trm2dvZCijh+S1/HTqGvCV3RkIx0O7bZkorZRqD2sVIBxQkJ9xQDNMMxJ630CW LVUiA+hb64A3M48l3SPawcufiMUozJglotcGxhOz6Py/xMRaPPxfUa6NzzuK6/m3T1gi xfyw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l64si1684306pfi.388.2018.02.16.11.23.54; Fri, 16 Feb 2018 11:24:10 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751439AbeBPS1Z convert rfc822-to-8bit (ORCPT + 99 others); Fri, 16 Feb 2018 13:27:25 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:46271 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751240AbeBPS1W (ORCPT ); Fri, 16 Feb 2018 13:27:22 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1emkjB-0004qa-3k; Fri, 16 Feb 2018 11:27:21 -0700 Received: from 174-19-85-160.omah.qwest.net ([174.19.85.160] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1emkjA-00024z-BA; Fri, 16 Feb 2018 11:27:20 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Enrico Weigelt Cc: "linux-kernel\@vger.kernel.org" , Linux Containers References: <0f058286-a432-379b-f559-f2fe713807ab@metux.net> <5633d335-3926-d98f-d6d7-948b1e2a0b2c@metux.net> Date: Fri, 16 Feb 2018 12:26:59 -0600 In-Reply-To: <5633d335-3926-d98f-d6d7-948b1e2a0b2c@metux.net> (Enrico Weigelt's message of "Tue, 13 Feb 2018 22:19:48 +0000") Message-ID: <87po54x024.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1emkjA-00024z-BA;;;mid=<87po54x024.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=174.19.85.160;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+aT4oPeXGPmYpTzR5dJ44/BBNRp7NX1yA= X-SA-Exim-Connect-IP: 174.19.85.160 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sa02.xmission.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,TVD_RCVD_IP,T_TM2_M_HEADER_IN_MSG autolearn=disabled version=3.4.0 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4998] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Enrico Weigelt X-Spam-Relay-Country: X-Spam-Timing: total 463 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.0 (0.7%), b_tie_ro: 2.00 (0.4%), parse: 1.33 (0.3%), extract_message_metadata: 29 (6.3%), get_uri_detail_list: 2.2 (0.5%), tests_pri_-1000: 12 (2.6%), tests_pri_-950: 2.1 (0.5%), tests_pri_-900: 1.68 (0.4%), tests_pri_-400: 26 (5.7%), check_bayes: 25 (5.3%), b_tokenize: 9 (2.0%), b_tok_get_all: 6 (1.4%), b_comp_prob: 3.7 (0.8%), b_tok_touch_all: 2.1 (0.5%), b_finish: 0.76 (0.2%), tests_pri_0: 372 (80.4%), check_dkim_signature: 0.85 (0.2%), check_dkim_adsp: 4.5 (1.0%), tests_pri_500: 9 (1.9%), rewrite_mail: 0.00 (0.0%) Subject: Re: plan9 semantics on Linux - mount namespaces X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Enrico Weigelt writes: > 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 ? suid root executables could be fooled. An easy case is fooling /bin/su into reading a different copy of /etc/shadow, and allowing arbitrary changes between users. >> 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 ? User namespaces limit the contained processes to not having any permissions outside of the user namespace. While still allowing the fully unix permission model inside user namespaces. I am in the final stages of getting the changes in the vfs and in fuse to allow unprivileged users to mount that filesystem. plan9fs would also be a candidate for that kind of treatment if it had a maintainer. Eric