From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: BUG: Mount ignores mount options Date: Sat, 11 Aug 2018 17:51:24 +0100 Message-ID: <20180811165123.GH6515@ZenIV.linux.org.uk> References: <87pnyphf8i.fsf@xmission.com> <87d0uqpba5.fsf@xmission.com> <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <22361.1533913891@warthog.procyon.org.uk> <30365.1533972586@warthog.procyon.org.uk> <9B6E2781-484B-4C42-95F5-F900EA36CEA5@amacapital.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <9B6E2781-484B-4C42-95F5-F900EA36CEA5-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apparmor-bounces-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org Sender: "AppArmor" To: Andy Lutomirski Cc: Eric Biggers , Tetsuo Handa , David Howells , selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org, tomoyo-dev-en-5NWGOfrQmneRv+LV9MX5uooqe+aC9MnS@public.gmane.org, Paul Moore , Miklos Szeredi , Stephen Smalley , fenghua.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, apparmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org, Greg Kroah-Hartman , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Theodore Y. Ts'o" , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Li Zefan , "Eric W. Biederman" , Johannes Weiner , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tejun Heo , torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org T24gU2F0LCBBdWcgMTEsIDIwMTggYXQgMDk6MzE6MjlBTSAtMDcwMCwgQW5keSBMdXRvbWlyc2tp IHdyb3RlOgoKPiBJIGRvbuKAmXQgc2VlIHdoeSB3ZSBuZWVkIGFsbCB0aGlzIGZhbmN5IOKAnGRv IHRoZSBvcHRpb25zIG1hdGNo4oCdIHN0dWZmLiAgRm9yIHRoZSBoYW5kZnVsIG9mIGZpbGVzeXN0 ZW1zIChsaWtlIE5GUykgdGhhdCBkbyBzb21ldGhpbmcgaW50ZWxsaWdlbnQgd2hlbiBtdWx0aXBs ZSBub24tYmluZCBtb3VudCByZXF1ZXN0cyBhZ2FpbnN0IHRoZSBzYW1lIHVuZGVybHlpbmcgc3Rv cmFnZSBoYXBwZW4sICB3ZSBjYW4ga2VlcCB0aGF0IGJlaGF2aW9yIGluIHRoZSBuZXcgQVBJLiBG b3Igb3RoZXIgZmlsZXN5c3RlbXMgdGhhdCBkb27igJl0IGhhdmUgdGhpcyBmZWF0dXJlLCB3ZSBz aG91bGQgc2ltcGx5IGZhaWwgdGhlIHJlcXVlc3QuCgo+IElPVyBJIHNlZSBzbyBjb21wZWxsaW5n IHJlYXNvbiB0byBjYWxsIHNnZXQoKSBhdCBhbGwgZnJvbSB0aGUgbmV3IEFQSS4gIFRoZSBvbmx5 IHNvcnQtb2YtbGVnaXQgdXNlIGNhc2UgSSBjYW4gdGhpbmsgb2YgaXMgbW91bnRpbmcgbW9yZSB0 aGFuIG9uZSBidHJmcyBzdWJ2b2x1bWUuIEJ1dCBldmVuIHRoYXQgc2hvdWxkIHByb2JhYmx5IG5v dCBiZSBkb25lIGJ5IGFza2luZyB0aGUga2VybmVsIHRvIHNlcGFyYXRlbHkgaW5zdGFudGlhdGUg dGhlIGZpbGVzeXN0ZW0uCgoKTWF5IEkgcG9saXRlbHkgc3VnZ2VzdCB0aGUgZXN0ZWVtZWQgcGFy dGljaXBhbnRzIG9mIHRoYXQgY29udmVyc2F0aW9uCnRvIFJURlM/ICBZZXMsIEkga25vdyB0aGF0 IGl0J3MgbGVzcyBmdW4gdGhhdCB0YWxraW5nIGFib3V0IHlvdXIKcmF0aGVyIHZhZ3VlIGlkZWFz IG9mIGhvdyB0aGUgdGhpbmdzIChzdXJlbHkpIHdvcmssIGJ1dCBpdCBqdXN0IG1pZ2h0CmF2b2lk IHRoZSBmZWF0cyBvZiBpZGlvY3kgbGlrZSB0aGUgYWJvdmUuCgpBbmR5LCBJIGRvbid0IGtub3cg aG93IHRvIHB1dCBpdCBtb3JlIHBsYWlubHk6IHJlYWQgdGhlIGZ1Y2tpbmcgc291cmNlLgpFdmVu IGdyZXAgd291bGQgZG8uICBUaGUgc2FtZSBORlMgeW91J3ZlIGdyYW50ZWQgKGFtb25nIHRoZSAi aGFuZGZ1bCIKb2YgZmlsZXN5c3RlbXMpIGFuIGV4Y2VwdGlvbiwgKkRPRVMqICpDQUxMKiAqVEhF KiAqRlVDS0lORyogc2dldCgpLgoKWWVzLCByZWFsbHkuICBBbmQgaW4gc29tZSBvYnNjdXJlWzFd IGNhc2VzIChpbmNsdWRpbmcgdGhlIG9uZSBtZW50aW9uZWQKdXB0aHJlYWQpIGl0IGRvZXMgcmV1 c2UgYSBwcmUtZXhpc3Rpbmcgc3VwZXJibG9jay4gIEZvciBhIHZlcnkgZ29vZApyZWFzb24uCgpb MV0gc3VjaCBhcywgb2gsIG1vdW50aW5nIHR3byBmaWxlc3lzdGVtcyBmcm9tIHRoZSBzYW1lIHNl cnZlciB3aXRoCmRlZmF1bHQgb3B0aW9ucyAtIHdobyB3b3VsZCd2ZSBldmVyIHRob3VnaHQgb2Yg ZG9pbmcgc29tZXRoaW5nIHNvCnBlcnZlcnRlZD8KCi0tIApBcHBBcm1vciBtYWlsaW5nIGxpc3QK QXBwQXJtb3JAbGlzdHMudWJ1bnR1LmNvbQpNb2RpZnkgc2V0dGluZ3Mgb3IgdW5zdWJzY3JpYmUg YXQ6IGh0dHBzOi8vbGlzdHMudWJ1bnR1LmNvbS9tYWlsbWFuL2xpc3RpbmZvL2FwcGFybW9yCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: viro@ZenIV.linux.org.uk (Al Viro) Date: Sat, 11 Aug 2018 17:51:24 +0100 Subject: BUG: Mount ignores mount options In-Reply-To: <9B6E2781-484B-4C42-95F5-F900EA36CEA5@amacapital.net> References: <87pnyphf8i.fsf@xmission.com> <87d0uqpba5.fsf@xmission.com> <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <22361.1533913891@warthog.procyon.org.uk> <30365.1533972586@warthog.procyon.org.uk> <9B6E2781-484B-4C42-95F5-F900EA36CEA5@amacapital.net> Message-ID: <20180811165123.GH6515@ZenIV.linux.org.uk> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Sat, Aug 11, 2018 at 09:31:29AM -0700, Andy Lutomirski wrote: > I don?t see why we need all this fancy ?do the options match? stuff. For the handful of filesystems (like NFS) that do something intelligent when multiple non-bind mount requests against the same underlying storage happen, we can keep that behavior in the new API. For other filesystems that don?t have this feature, we should simply fail the request. > IOW I see so compelling reason to call sget() at all from the new API. The only sort-of-legit use case I can think of is mounting more than one btrfs subvolume. But even that should probably not be done by asking the kernel to separately instantiate the filesystem. May I politely suggest the esteemed participants of that conversation to RTFS? Yes, I know that it's less fun that talking about your rather vague ideas of how the things (surely) work, but it just might avoid the feats of idiocy like the above. Andy, I don't know how to put it more plainly: read the fucking source. Even grep would do. The same NFS you've granted (among the "handful" of filesystems) an exception, *DOES* *CALL* *THE* *FUCKING* sget(). Yes, really. And in some obscure[1] cases (including the one mentioned upthread) it does reuse a pre-existing superblock. For a very good reason. [1] such as, oh, mounting two filesystems from the same server with default options - who would've ever thought of doing something so perverted? From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 11 Aug 2018 17:51:24 +0100 From: Al Viro To: Andy Lutomirski Cc: David Howells , "Eric W. Biederman" , John Johansen , Tejun Heo , selinux@tycho.nsa.gov, Paul Moore , Li Zefan , linux-api@vger.kernel.org, apparmor@lists.ubuntu.com, Casey Schaufler , 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, "Theodore Y. Ts'o" , Miklos Szeredi Message-ID: <20180811165123.GH6515@ZenIV.linux.org.uk> References: <87pnyphf8i.fsf@xmission.com> <87d0uqpba5.fsf@xmission.com> <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <22361.1533913891@warthog.procyon.org.uk> <30365.1533972586@warthog.procyon.org.uk> <9B6E2781-484B-4C42-95F5-F900EA36CEA5@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 In-Reply-To: <9B6E2781-484B-4C42-95F5-F900EA36CEA5@amacapital.net> Sender: Al Viro Subject: Re: BUG: Mount ignores mount options List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: On Sat, Aug 11, 2018 at 09:31:29AM -0700, Andy Lutomirski wrote: > I don’t see why we need all this fancy “do the options match” stuff. For the handful of filesystems (like NFS) that do something intelligent when multiple non-bind mount requests against the same underlying storage happen, we can keep that behavior in the new API. For other filesystems that don’t have this feature, we should simply fail the request. > IOW I see so compelling reason to call sget() at all from the new API. The only sort-of-legit use case I can think of is mounting more than one btrfs subvolume. But even that should probably not be done by asking the kernel to separately instantiate the filesystem. May I politely suggest the esteemed participants of that conversation to RTFS? Yes, I know that it's less fun that talking about your rather vague ideas of how the things (surely) work, but it just might avoid the feats of idiocy like the above. Andy, I don't know how to put it more plainly: read the fucking source. Even grep would do. The same NFS you've granted (among the "handful" of filesystems) an exception, *DOES* *CALL* *THE* *FUCKING* sget(). Yes, really. And in some obscure[1] cases (including the one mentioned upthread) it does reuse a pre-existing superblock. For a very good reason. [1] such as, oh, mounting two filesystems from the same server with default options - who would've ever thought of doing something so perverted?