On Fri, 2018-06-01 at 06:40 -0500, Goldwyn Rodrigues wrote:
>
> On 05/31/2018 07:49 PM, Trond Myklebust wrote:
> > On Thu, 2018-05-31 at 16:53 -0500, Goldwyn Rodrigues wrote:
> > >
> > > On 05/31/2018 08:30 AM, Miklos Szeredi wrote:
> > > > On Thu, May 31, 2018 at 3:10 PM, Trond Myklebust
> > > > <trondmy@xxxxxxxxxxxxxxx> wrote:
> > > > > >
> > > > > > I understand. Ignoring nfs4_acl in overlayfs will have the
> > > > > > same
> > > > > > result as adding noacl to the underlying NFS mount.
> > >
> > > Adding noacl in NFS client mount has no affect to nfs4_acl. Only
> > > if
> > > you
> > > add noacl in the underlying filesystem of exported directory in
> > > the
> > > server does the nfs4_acl go away.
> >
> > That would also be specific to Linux servers.
>
> Sorry, I don't have access to other NFS based servers. Does that mean
> "noacl" option on NFS client mount has different interpretations for
> different NFS servers? Or do you mean that nfs4_acl cannot be
> disabled
> for other type of servers?
I'm not sure it even makes sense to turn off filesystem acls if your
underlying filesystem is something like zfs or apfs (let alone NTFS).
Linux really is behind the curve here.
> >
> > So if that is your final decision, then why not just state in the
> > overlayfs manpage that
>
> No, that is not my final decision. Neither is it for me to make. I am
> merely trying to find a way to make writes on overlayfs possible with
> NFSv4 in the lower layer.
>
...and all I'm doing is pointing out that as long as you insist on
client enforcement of file security, then you are heavily limiting the
list of servers and server configurations that you will be able to work
safely with. There is a reason why, in all the 30 years since the NFSv2
spec was released, nobody has built such a client.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
