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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 7EEEDC4338F for ; Thu, 19 Aug 2021 13:57:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 65FF16113B for ; Thu, 19 Aug 2021 13:57:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240159AbhHSN6b convert rfc822-to-8bit (ORCPT ); Thu, 19 Aug 2021 09:58:31 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:59828 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240200AbhHSN6X (ORCPT ); Thu, 19 Aug 2021 09:58:23 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]:57326) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mGiY4-000ia2-O6; Thu, 19 Aug 2021 07:57:36 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:52186 helo=email.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mGiY3-00AqBr-Kq; Thu, 19 Aug 2021 07:57:36 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: bfields@fieldses.org (J. Bruce Fields) Cc: Andy Lutomirski , Linus Torvalds , David Laight , David Hildenbrand , Linux Kernel Mailing List , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Al Viro , Alexey Dobriyan , Steven Rostedt , "Peter Zijlstra \(Intel\)" , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Petr Mladek , Sergey Senozhatsky , Andy Shevchenko , Rasmus Villemoes , Kees Cook , Greg Ungerer , Geert Uytterhoeven , Mike Rapoport , Vlastimil Babka , Vincenzo Frascino , Chinwen Chang , Michel Lespinasse , Catalin Marinas , "Matthew Wilcox \(Oracle\)" , Huang Ying , Jann Horn , Feng Tang , Kevin Brodsky , Michael Ellerman , Shawn Anastasio , Steven Price , Nicholas Piggin , Christian Brauner , Jens Axboe , Gabriel Krisman Bertazi , Peter Xu , Suren Baghdasaryan , Shakeel Butt , Marco Elver , Daniel Jordan , Nicolas Viennot , Thomas Cedeno , Collin Fijalkovich , Michal Hocko , Miklos Szeredi , Chengguang Xu , Christian =?utf-8?Q?K=C3=B6nig?= , "linux-unionfs\@vger.kernel.org" , Linux API , the arch/x86 maintainers , "\" , Linux-MM , Florian Weimer , Michael Kerrisk References: <20210812084348.6521-1-david@redhat.com> <87o8a2d0wf.fsf@disp2133> <60db2e61-6b00-44fa-b718-e4361fcc238c@www.fastmail.com> <87lf56bllc.fsf@disp2133> <87eeay8pqx.fsf@disp2133> <5b0d7c1e73ca43ef9ce6665fec6c4d7e@AcuMS.aculab.com> <87h7ft2j68.fsf@disp2133> <20210818154217.GB24115@fieldses.org> Date: Thu, 19 Aug 2021 08:56:52 -0500 In-Reply-To: <20210818154217.GB24115@fieldses.org> (J. Bruce Fields's message of "Wed, 18 Aug 2021 11:42:17 -0400") Message-ID: <87bl5tv8pn.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1mGiY3-00AqBr-Kq;;;mid=<87bl5tv8pn.fsf@disp2133>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+peADQdS13oBRstgvxG3nqTM38ZOsjU00= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-unionfs@vger.kernel.org bfields@fieldses.org (J. Bruce Fields) writes: > On Fri, Aug 13, 2021 at 05:49:19PM -0700, Andy Lutomirski wrote: >> I’ll bite. How about we attack this in the opposite direction: remove >> the deny write mechanism entirely. > > For what it's worth, Windows has open flags that allow denying read or > write opens. They also made their way into the NFSv4 protocol, but > knfsd enforces them only against other NFSv4 clients. Last I checked, > Samba attempted to emulate them using flock (and there's a comment to > that effect on the flock syscall in fs/locks.c). I don't know what Wine > does. > > Pavel Shilovsky posted flags adding O_DENY* flags years ago: > > https://lwn.net/Articles/581005/ > > I keep thinking I should look back at those some day but will probably > never get to it. > > I've no idea how Windows applications use them, though I'm told it's > common. I don't know in any detail. I just have this memory of not being able to open or do anything with a file on windows while any application has it open. We limit mandatory locks to filesystems that have the proper mount flag and files that are sgid but are not executable. Reusing that limit we could probably allow such a behavior in Linux without causing chaos. Without being very strict about which files can participate I can just imagine someone hiding their presence by not allowing other applications the ability to write to utmp or a log file. In the windows world where everything evolved with those kinds of restrictions it is probably fine (although super annoying). Eric