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, 3 May 2019 11:27:02 -0400
From:   "J. Bruce Fields" <>
To:     "Goetz, Patrick G" <>
Cc:     Andreas Gruenbacher <>,
        NeilBrown <>, Amir Goldstein <>,
        Miklos Szeredi <>,
        Andreas Gr├╝nbacher 
        Patrick Plagwitz <>,
        "" <>,
        Linux NFS list <>,
        Linux FS-devel Mailing List <>,
        Linux Kernel Mailing List <>
Subject: Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Thu, May 02, 2019 at 05:51:12PM +0000, Goetz, Patrick G wrote:
> On 5/2/19 12:44 PM, Andreas Gruenbacher wrote:
> > On Thu, 2 May 2019 at 19:27, Goetz, Patrick G <> wrote:
> >> On 5/1/19 10:57 PM, NeilBrown wrote:
> >>> Support some day support for nfs4 acls were added to ext4 (not a totally
> >>> ridiculous suggestion).  We would then want NFS to allow it's ACLs to be
> >>> copied up.
> >>
> >> Is there some reason why there hasn't been a greater effort to add NFSv4
> >> ACL support to the mainstream linux filesystems?  I have to support a
> >> hybrid linux/windows environment and not having these ACLs on ext4 is a
> >> daily headache for me.
> > 
> > The patches for implementing that have been rejected over and over
> > again, and nobody is working on them anymore.
> > 
> > Andreas
> That's the part I don't understand -- why are the RichACL patches being 
> rejected?

Looking back through old mail....:

	For one I still see no reason to merge this broken ACL model at
	all.  It provides our actualy Linux users no benefit at all,
	while breaking a lot of assumptions, especially by adding allow
	and deny ACE at the same sime.

	It also doesn't help with the issue that the main thing it's
	trying to be compatible with (Windows) actually uses a
	fundamentally different identifier to apply the ACLs to - as
	long as you're still limited to users and groups and not guids
	we'll still have that mapping problem anyway.

Christoph also had some objections to the implementation which I think
were addressed, but I could be wrong.


Powered by blists - more mailing lists