On Tue, 2018-07-17 at 15:18 +0200, Christoph Hellwig wrote: > On Mon, Jul 16, 2018 at 05:07:48PM -0700, Andrew Morton wrote: > > > > On Sat, 14 Jul 2018 12:11:03 -0700 Viacheslav Dubeyko <slava@dubeyk > > o.com> wrote: > > > > > > > > On Sat, 2018-07-14 at 16:06 -0300, Ernesto A. Fernández wrote: > > > > > > > > The HFS+ Access Control Lists have not worked at all for the > > > > past > > > > five > > > > years, and nobody seems to have noticed. Besides, POSIX draft > > > > ACLs > > > > are > > > > not compatible with MacOS. Drop the feature entirely. > > > > > > > Bugs need to be fixed but not to drop. Otherwise, it needs to > > > drop the > > > whole HFS+ support from the kernel. > > Yes, we could make it depend on BROKEN and hope that someone comes > > along and fixes it - there's little cost in carrying such a thing. > > > > Or maybe it can never work for some reason and should indeed be > > dropped, I don't know. I was interested in understanding the > > reasoning > > behind hch's ack, but I can't find it on linux-fs-devel. Help? > The issue is that hfsplus supports it's own NFSv4-like ACLs, which > are nothing like the Posix ACLs supported by the Linux driver. Or > in other words: they were always a Linux-only incompatible extension > that should never have been merged. The richacls subsystem was not in the kernel at the time of ACL support implementation. So, the idea of Linux-like ACLs in HFS+ was not to be compatible with MAC OS X. The goal was to provide the opportunity to use the ACLs only in Linux if anybody likes this. The MAC OS X will ignore such xattrs. As far as I can see, the ACL subsystem in HFS+ stops to work after Christoph's reworking the ACL subsystem in the Linux. So, we have richacls subsystem in the Linux kernel now. I believe that it makes sense to implement the richacls support in HFS+ at first. Then we can discuss to drop or not to drop the current ACL implementation in HFS+. Also, there is CONFIG_HFSPLUS_FS_POSIX_ACL option that provides opportunity to exclude the ACL support in HFS+ from the compilation. Thanks, Vyacheslav Dubeyko.
