linux-kernel - Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 10 May 2019 16:09:41 -0400
From:   "J. Bruce Fields" <bfields@...ldses.org>
To:     NeilBrown <neilb@...e.com>
Cc:     Andreas Gruenbacher <agruenba@...hat.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        Andreas Grünbacher 
        <andreas.gruenbacher@...il.com>,
        Patrick Plagwitz <Patrick_Plagwitz@....de>,
        "linux-unionfs@...r.kernel.org" <linux-unionfs@...r.kernel.org>,
        Linux NFS list <linux-nfs@...r.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Tue, May 07, 2019 at 10:24:58AM +1000, NeilBrown wrote:
> Interesting perspective .... though doesn't NFSv4 explicitly allow
> client-side ACL enforcement in the case of delegations?

Not really.  What you're probably thinking of is the single ACE that the
server can return on granting a delegation, that tells the client it can
skip the ACCESS check for users matching that ACE.  It's unclear how
useful that is.  It's currently unused by the Linux client and server.

> Not sure how relevant that is....
> 
> It seems to me we have two options:
>  1/ declare the NFSv4 doesn't work as a lower layer for overlayfs and
>     recommend people use NFSv3, or
>  2/ Modify overlayfs to work with NFSv4 by ignoring nfsv4 ACLs either
>  2a/ always - and ignore all other acls and probably all system. xattrs,
>  or
>  2b/ based on a mount option that might be
>       2bi/ general "noacl" or might be
>       2bii/ explicit "noxattr=system.nfs4acl"
>  
> I think that continuing to discuss the miniature of the options isn't
> going to help.  No solution is perfect - we just need to clearly
> document the implications of whatever we come up with.
> 
> I lean towards 2a, but I be happy with with any '2' and '1' won't kill
> me.

I guess I'd also lean towards 2a.

I don't think it applies to posix acls, as overlayfs is capable of
copying those up and evaluating them on its own.

--b.

> 
> Do we have a vote?  Or does someone make an executive decision??
> 
> NeilBrown