In message <20160619080803.GA1638@brick>, Edward Tomasz =?utf-8?Q?Napiera=C5=82 a?= writes: > On 0614T0232, Jan Beich wrote: > > Alexander Motin <m...@freebsd.org> writes: > > > > > Author: mav > > > Date: Wed May 11 13:43:20 2016 > > > New Revision: 299448 > > > URL: https://svnweb.freebsd.org/changeset/base/299448 > > > > > > Log: > > > MFV r299442: 6762 POSIX write should imply DELETE_CHILD on directories > - and > > > some additional considerations > > > > > > Reviewed by: Gordon Ross <g...@nexenta.com> > > > Reviewed by: Yuri Pankov <yuri.pan...@nexenta.com> > > > Author: Kevin Crowe <kevin.cr...@nexenta.com> > > > > > > openzfs/openzfs@d316fffc9c361532a482208561bbb614dac7f916 > > > > This commit confuses acl_is_trivial_np(3). Notice '+' in ls(1) and 'D' > > in getfacl(1) outputs. > > It's not just that. > > Those changes: > > 1. Confuse acl_is_trivial_np(3), as you say. It's hard to fix in libc, > because they make trivial ACLs different for files and directories, > and acl_is_trivial_np(3) has no way of telling which is which. > > 2. They make delete deny permission take precedence over the containing > directory write allow permission, which is rather different from what > people expect in unix systems, and is against the NFSv4 specification, > even though it might be a better fit for Windows.
This is Windows behavior and inconsistent with the rest of FreeBSD and any UNIX or Linux system. > > 3. They make umask apply to inherit_only permissions, and > > 4. I don't fully understand this one yet, but from the ACL regression > test suite (which lives in tests/sys/acl/, and I'd appreciate people > actually ran this before committing ACL-related changes) it looks > like it makes umask not apply to the stuff it should. > > The #1 could be fixed by making ZFS not setting delete_child on write, > basically reverting to the previous behaviour in that aspect. As for > the others... I'm not saying each one of those is wrong, but they > certainly warrant further discussion, especially #2 and #4. I think #2 is wrong behavior on any UNIX-like or POSIX system. > > Basically, what I'm trying to say is that we should consider backing > this out for 11.0-RELEASE, reverting to the previous semantics, verified > by passing the regression tests. Agreed. What in FreeBSD was this patch supposed to solve in the first place? -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
