From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C523C4646D for ; Wed, 15 Aug 2018 04:03:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C38FF215F9 for ; Wed, 15 Aug 2018 04:03:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C38FF215F9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728760AbeHOGxt (ORCPT ); Wed, 15 Aug 2018 02:53:49 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:49234 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728480AbeHOGxt (ORCPT ); Wed, 15 Aug 2018 02:53:49 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fpn1n-0000Gx-MC; Tue, 14 Aug 2018 22:03:23 -0600 Received: from [97.119.167.31] (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 1fpn1n-00007B-3m; Tue, 14 Aug 2018 22:03:23 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Casey Schaufler Cc: "Theodore Y. Ts'o" , Al Viro , David Howells , John Johansen , Tejun Heo , selinux@tycho.nsa.gov, Paul Moore , Li Zefan , linux-api@vger.kernel.org, apparmor@lists.ubuntu.com, fenghua.yu@intel.com, Greg Kroah-Hartman , Eric Biggers , linux-security-module@vger.kernel.org, Tetsuo Handa , Johannes Weiner , Stephen Smalley , tomoyo-dev-en@lists.sourceforge.jp, cgroups@vger.kernel.org, torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Miklos Szeredi References: <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <87d0uqpba5.fsf@xmission.com> <20180810151606.GA6515@ZenIV.linux.org.uk> <87pnypiufr.fsf@xmission.com> <20180811014619.GA14368@thunk.org> <8736vlo6ef.fsf@xmission.com> <001a1608-d0fa-84c1-9c54-ae36df95fd89@schaufler-ca.com> Date: Tue, 14 Aug 2018 23:03:17 -0500 In-Reply-To: <001a1608-d0fa-84c1-9c54-ae36df95fd89@schaufler-ca.com> (Casey Schaufler's message of "Sat, 11 Aug 2018 10:47:50 -0700") Message-ID: <87d0ukjmyi.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=1fpn1n-00007B-3m;;;mid=<87d0ukjmyi.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=97.119.167.31;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/6JXSadUqNHy+yUkMND0RDRAYIEtspPLg= X-SA-Exim-Connect-IP: 97.119.167.31 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: BUG: Mount ignores mount options 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 Casey Schaufler writes: > Don't blame the filesystems for behaving as documented. No. This behavior is not documented. At least I certainly don't see a word about this in any of the man pages. Where does it say mounting a filesystem will not honor it's mount options? It is also rare enough in practice it is something it is reasonable to expect people to be surprised by. > The problem is not in the mount mechanism, it's in the way you want to > abuse it. I am not asking for this behavior. I am pointing out this behavior exists. I am pointing out this behavior is harmful. I am asking we stop doing this harmful thing in the new API where we don't have a chance of breaking anything. The place where this has bitten the hardest is someone wrote a script to do something for Xen in a chroot. That script involved a chroot that mounted devpts and in doing so happend to change the options of the main /dev/pts. Which resulted in ptys created with /dev/ptmx outside the chroot with the wrong permissions. That in turn caused several distros to retain the ancient suid pt_chown binary from libc that the devpts filesystem was built to make obsolete. As the world turned that pt_chown binary could be confused into chowning the wrong pty if a pty from a container was used. The fix was to mount a new instance of devpts every time mount of devpts is called. That simplified the code, and allowed pt_chown to be removed permanently. The tricky bit was figuring out how keep /dev/ptmx working. I wound up testing on every distribution I could think of to ensure no one would notice the slightly changed behavior of the devpts filesystem. The behavior in other filesystems of ignoring the options instead of changing them on the filesystem isn't quite as bad. But it still has the potential for a lot of mischief. Eric