Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAOQ4uxjQdLrZXkpP30Pq_=Cckcb=mADrEwQUXmsG92r-gn2y5w@mail.gmail.com>
 <379106947f859bdf5db4c6f9c4ab8c44f7423c08.camel@kernel.org>
 <CAOQ4uxgewN=j3ju5MSowEvwhK1HqKG3n1hBRUQTi1W5asaO1dQ@mail.gmail.com>
 <930108f76b89c93b2f1847003d9e060f09ba1a17.camel@kernel.org>
 <CAOQ4uxgQsRaEOxz1aYzP1_1fzRpQbOm2-wuzG=ABAphPB=7Mxg@mail.gmail.com>
 <20190426140023.GB25827@fieldses.org> <CAOQ4uxhuxoEsoBbvenJ8eLGstPc4AH-msrxDC-tBFRhvDxRSNg@mail.gmail.com>
 <20190426145006.GD25827@fieldses.org> <e69d149c80187b84833fec369ad8a51247871f26.camel@kernel.org>
 <CAOQ4uxjt+MkufaJWoqWSYZbejWa1nJEe8YYRroEBSb1jHjzkwQ@mail.gmail.com>
 <8504a05f2b0462986b3a323aec83a5b97aae0a03.camel@kernel.org>
 <CAOQ4uxi6fQdp_RQKHp-i6Q-m-G1+384_DafF3QzYcUq4guLd6w@mail.gmail.com>
 <1d5265510116ece75d6eb7af6314e6709e551c6e.camel@hammerspace.com>
 <CAOQ4uxjUBRt99efZMY8EV6SAH+9eyf6t82uQuKWHQ56yjpjqMw@mail.gmail.com>
 <95bc6ace0f46a1b1a38de9b536ce74faaa460182.camel@hammerspace.com>
 <CAOQ4uxhQOLZ_Hyrnvu56iERPZ7CwfKti2U+OgyaXjM9acCN2LQ@mail.gmail.com>
 <b4ee6b6f5544114c3974790a784c3e784e617ccf.camel@hammerspace.com>
 <bc2f04c55ba9290fc48d5f2b909262171ca6a19f.camel@kernel.org> <BYAPR21MB1303596634461C7D46B0A773B6390@BYAPR21MB1303.namprd21.prod.outlook.com>
In-Reply-To: <BYAPR21MB1303596634461C7D46B0A773B6390@BYAPR21MB1303.namprd21.prod.outlook.com>
From:   Amir Goldstein <amir73il@gmail.com>
Date:   Mon, 29 Apr 2019 20:31:37 -0400
Message-ID: <CAOQ4uxirAW91yUe1nQUPPmarmMSxr_pco8NqKWB4srwyvgnRRA@mail.gmail.com>
Subject: Re: Better interop for NFS/SMB file share mode/reservation
To:     Pavel Shilovskiy <pshilov@microsoft.com>
Cc:     Jeff Layton <jlayton@kernel.org>,
        Trond Myklebust <trondmy@hammerspace.com>,
        "bfields@fieldses.org" <bfields@fieldses.org>,
        "samba-technical@lists.samba.org" <samba-technical@lists.samba.org>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "Volker.Lendecke@sernet.de" <Volker.Lendecke@sernet.de>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        Pavel Shilovsky <piastryyy@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

...
> > > No. I'm saying that whether you intended to or not, you _are_
> > > implementing a mandatory lock over NFS. No talk about O_SHARE flags a=
nd
> > > it being an opt-in process for local applications changes the fact th=
at
> > > non-local applications (i.e. the ones that count ) are being subjecte=
d
> > > to a mandatory lock with all the potential for denial of service that
> > > implies.
> > > So we need a mechanism beyond O_SHARE in order to ensure this system
> > > cannot be used on sensitive files that need to be accessible to all. =
It
> > > could be an export option, or a mount option, or it could be a more
> > > specific mechanism (e.g. the setgid with no execute mode bit as using
> > > in POSIX mandatory locks).
> > >
> >
> > That's a great point.
> >
> > I was focused on the local fs piece in order to support NFS/SMB serving=
,
> > but we also have to consider that people using nfs or cifs filesystems
> > would want to use this interface to have their clients set deny bits as
> > well.
> >
> > So, I think you're right that we can't really do this without involving
> > non-cooperating processes in some way.
>
> It's been 5+ years since I touched that code but I still like the idea of=
 having a separate mount option for mountpoints used by Samba and NFS serve=
rs and clients to avoid security attacks on the sensitive files. For some s=
ensitive files on such mountpoints a more selective mechanism may be used t=
o prevent deny flags to be set (like mentioned above). Or we may think abou=
t adding another flag e.g. O_DENYFORCE available to root only that tells th=
e kernel to not take into account deny flags already set on a file - might =
be useful for recovery tools.
>
> About O_DENYDELETE: I don't understand how we may reach a good interop st=
ory without a proper implementation of this flag. Windows apps may set it a=
nd Samba needs to respect it. If an NFS client removes such an opened file,=
 what will Samba tell the Windows client?
>

Samba will tell the Windows client:
"Sorry, my administrator has decided to trade off interop with nfs on
share modes,
with DENY_DELETE functionality, so I cannot grant you DENY_DELETE that you
requested."
Not sure if that is workable. Samba developers need to chime in.

Thanks,
Amir.