Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp5448347imm; Tue, 12 Jun 2018 08:01:36 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJR2PJhcVaN8Ig67SJA4beIQXE9NzOXV6XODMiq37lfI8uRHDReK8T9ebq+k8U2TRgvxumD X-Received: by 2002:a17:902:530e:: with SMTP id b14-v6mr826974pli.316.1528815696206; Tue, 12 Jun 2018 08:01:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528815696; cv=none; d=google.com; s=arc-20160816; b=pRWXgyU01/1gpsMpJhzkwhB0vKCaRkfRZzuhGy/9HXGX+RNQp5FZXDxcSJXEZK0g5Z K8FiNStB58mYXpZKNM4a82JdJl0XL/D7x4Q8kLhi/jGNaevmn7jJA+4HOxr/jlwHkcmF akyf8mRQgcTRC/RU7tK6Jc/ZhwxdS8YQ3lcmXWnzJr8tBftP2bnX4Ue2OdqRJhOlEOTh 6pUXjh1X6eKPmiDtkVqLW/iHE/1i5eFophRzuvO9/Uafbz25d5MgRNLxpB+hZGjbm7zk iFZ7oxXl4saGJ4o0wsWkPW6+FA14ejVK/cihxjb0O4jTZ4JpIi1oVUf9q+Kz9sXChyZY g0lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from :arc-authentication-results; bh=oLL9yBrnfIkwq883Qzwk11P/IWOOQicdQWHgmoOl8Mw=; b=WkoDxl+jd9jduZrTEf9py1DLwsyNVjBY4JfvqLuJy0WriLQnhbAvpXlKHcYjAvxYJQ 6oszCpMX1t8MLmQfc3uLTwVZMoUoMJlzOeXhdwxTkM3BZiwVWgEAnybumEp7P3uiWaaM VY7Pos2Q7be92gC6M8xaPau2uimIPLXdzmwt37RxRacl6hihuyoSdwUtRIXznE3Wyhxs RYITOMSPg3NLppdw+YowSfHk/yj+0J0YMwr27HaIXAoNE7CwGt5ZB0K6dwOzABXijMj2 1DvcaTOQA8OPJmOnTFbFJxaju1MJTgJaXC1SCz7xKdR8nMS8/KHBbpr/Ql/q1Mta8CeA 3hAg== 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 j20-v6si317932pll.211.2018.06.12.08.01.18; Tue, 12 Jun 2018 08:01:36 -0700 (PDT) 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 S934296AbeFLO7s (ORCPT + 99 others); Tue, 12 Jun 2018 10:59:48 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:44697 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932750AbeFLO7p (ORCPT ); Tue, 12 Jun 2018 10:59:45 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fSkls-0006ie-MO; Tue, 12 Jun 2018 08:59:44 -0600 Received: from 97-119-124-205.omah.qwest.net ([97.119.124.205] 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 1fSklr-0004dL-Nz; Tue, 12 Jun 2018 08:59:44 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Alistair Strachan Cc: linux-fsdevel@vger.kernel.org, Seth Forshee , Djalal Harouni , kernel-team@android.com, linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org References: <20180611195744.154962-1-astrachan@google.com> <87bmcgpzno.fsf@xmission.com> Date: Tue, 12 Jun 2018 09:59:36 -0500 In-Reply-To: (Alistair Strachan's message of "Mon, 11 Jun 2018 23:12:35 -0700") Message-ID: <87fu1svynb.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1fSklr-0004dL-Nz;;;mid=<87fu1svynb.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=97.119.124.205;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19jI0VjCmJAzfBHz3/gHhXPxvYwEDUA4Is= X-SA-Exim-Connect-IP: 97.119.124.205 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa04.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.1 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.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Alistair Strachan X-Spam-Relay-Country: X-Spam-Timing: total 427 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.3 (0.8%), b_tie_ro: 2.4 (0.6%), parse: 1.56 (0.4%), extract_message_metadata: 21 (4.9%), get_uri_detail_list: 7 (1.6%), tests_pri_-1000: 9 (2.0%), tests_pri_-950: 1.94 (0.5%), tests_pri_-900: 1.29 (0.3%), tests_pri_-400: 40 (9.3%), check_bayes: 38 (9.0%), b_tokenize: 15 (3.6%), b_tok_get_all: 12 (2.8%), b_comp_prob: 5.0 (1.2%), b_tok_touch_all: 3.4 (0.8%), b_finish: 0.71 (0.2%), tests_pri_0: 339 (79.4%), check_dkim_signature: 0.60 (0.1%), check_dkim_adsp: 4.3 (1.0%), tests_pri_500: 6 (1.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] proc: Fix parsing of mount parameters. 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 Alistair Strachan writes: > On Mon, Jun 11, 2018 at 6:22 PM Eric W. Biederman wrote: >> >> Alistair Strachan writes: >> >> > In commit e94591d0d90c "proc: Convert proc_mount to use mount_ns" >> > the parsing of mount parameters for the proc filesystem was broken. >> > >> > The SB_KERNMOUNT for procfs happens via: >> > >> > start_kernel() >> > rest_init() >> > kernel_thread() >> > _do_fork() >> > copy_process() >> > alloc_pid() >> > pid_ns_prepare_proc() >> > kern_mount_data() >> > proc_mount() >> > mount_ns() >> > >> > In mount_ns(), the kernel calls proc_fill_super() only if the superblock >> > has not previously been set up (i.e. the first mount reference), >> > regardless of SB_KERNMOUNT. Because the call to proc_parse_options() had >> > been moved inside here, and the SB_KERNMOUNT uses no mount options, the >> > option parser became a no-op. >> > >> > When userspace later mounted procfs with e.g. hidepid=2, the options >> > would be ignored. >> > >> > This change backs out a part of the original cleanup and parses the >> > procfs mount options at every mount call. Because the options currently >> > only update the pid_ns for the mount, they are applied for all mounts of >> > proc by that pid or childen of that pid, instantaneously. This is the >> > same behavior as the original code. >> >> Two years for a regression to be reported is a litte long. I think that >> gets out of the kneejerk immediate fix or revert phase and into thinking >> a little bout about what makes sense in this code. > > Android has been using hidepid=2 for a while, but most shipping > products were on 3.18 or 4.4 kernels. To us, it's a new problem. All that says is that no one from Android has looked at or tested a kernel (not even a stable one) since 4.4. That does not work for justifying changes/fixes to the kernel. People working together does not work to well when some of the people don't show up. As an engineer I sympathize with your position. Whoever made the decision that Android won't care for anything except for the best effort long term stable kernels has made your job a challenge. I do appreciate that Android at least periodically updates their kernels. The bottom line though is that if this had been caught within the release or so of it's breaking restoring the old userspace behavior would not have been a question. Now after two years there is the question of if other people have come to depend on the new behavior. >> As we say with devpts there is a very real danger of someone mounting >> a second instance of proc in a chroot and causing problems by either >> strengthening or weakening the hid pid protections for the entire pid >> namespace. If we go with your proposed change in behavior. > > I guess my change does change the behavior, but it's just back to the > behavior which the kernel had for a good while (~v3.3 thru v4.7). > >> Ordinary block device filesystems (like ext4) avoid this problem by >> allowing a second mount and by not parsing the mount options except >> on remount. What proc currently does. > > IMHO, they're not really comparable. You'll only get kernmounts of an > ext4 filesystem when finding rootfs, and in that case the user knows > about the mount and can see it in /proc/mounts, so they know to use -o > remount,. > > Since the first mount (where the options might have been respected) is > *always* the kernmount done before init, with your change these mount > options for procfs will never be respected. As userspace didn't yet > mount /proc, it can't know /proc was already mounted, in order to know > to use a remount to re-parse the options. The behavior was changed in > a non-obvious way. Please not it is fundamentally required if the in kernel superblocks are going to be shared. >> So I think it can be reasonably argued that the change in behavior is >> was an unintentional fix. >> >> I can see an argument for failing the mount of proc if mount options >> are specified or if those mount options differ from the existing mount >> options. >> >> proc_remount's call of proc_parse_options is definitely buggy as it can >> partially succeed and change the pid namespace and return an error code. >> That is bad error handling. >> >> There may be an argument for making these options available in something >> other than a mount of proc. As they are pid namespace wide. >> >> There may be an argument for multiple instances of proc so that it makes >> sense to process these options during an ordinary mount. >> >> >> Ultimately what I see is that this is a difficult area of semantics that >> there is at least a little room for improvement on, but it is not >> as simple as this proposed change. > > An alternative fix might be to ignore the super setup if done from a > kernmount of procfs. IMO, this initial mount shouldn't be considered > the first reference, because it will not pass the mount options and > cannot be observed by userspace. Such a change looks complicated, > though, and it would only be relevant to procfs. It might be better to > roll back the cleanup and implement these semantics directly in the > procfs code. That would be straight forward if we could get rid of proc_mnt. Then there would not need to be an internal kernel mount. Which would get us there and that would probably be a nice cleanup. We can hand wave away the uml mconsole and sysctl syscall uses of proc_mnt. The tricky case is proc_flush_task. That requires someone having a reference to the proc super block and it noticably keeps the amount of memory consumed by the proc filesystem down. Enough so that people notice when it is not performing well. I have heard of people running Android in a chroot on chrome books, and I have heard of people running normal linux chroots on Android phones. So chroots and people mounting proc for a second time are definitely things to worry about in the real world. So I strongly suspect the old behavior is quite risky in those real world situations. At this moment I really hate mount options to proc. They are quite difficult to make work well and in a non-surprising way. Eric