From owner-svn-src-all@freebsd.org Sun Jun 19 19:52:04 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6899FA7915D; Sun, 19 Jun 2016 19:52:04 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [5.9.78.60]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7552E5E; Sun, 19 Jun 2016 19:52:03 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from [IPv6:2a02:2450:1023:80df:ec62:d80e:1be2:9454] (unknown [IPv6:2a02:2450:1023:80df:ec62:d80e:1be2:9454]) by mail.vx.sk (Postfix) with ESMTPSA id BA06E9DED1; Sun, 19 Jun 2016 21:52:01 +0200 (CEST) Subject: Re: svn commit: r299448 - in head/sys/cddl/contrib/opensolaris: common/acl uts/common/fs/zfs uts/common/sys To: Alexander Motin , Cy Schubert , Jan Beich , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201606191428.u5JESbbs053857@slippy.cwsent.com> <49d3d34d-ba91-ebdf-497f-cbe1614bec53@FreeBSD.org> From: Martin Matuska Message-ID: Date: Sun, 19 Jun 2016 21:52:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <49d3d34d-ba91-ebdf-497f-cbe1614bec53@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 19:52:04 -0000 I highly suggest dealing with this at OpenZFS: - opening an issue at Ilumos - discussing this on the developer@open-zfs.org mailing list On 19.06.2016 16:33, Alexander Motin wrote: > On 19.06.16 17:28, Cy Schubert wrote: >> In message <20160619080803.GA1638@brick>, Edward Tomasz=20 >> =3D?utf-8?Q?Napiera=3DC5=3D82 >> a?=3D writes: >>> On 0614T0232, Jan Beich wrote: >>>> Alexander Motin 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 direct= ories=20 >>> - and >>>>> some additional considerations >>>>> =20 >>>>> Reviewed by: Gordon Ross >>>>> Reviewed by: Yuri Pankov >>>>> Author: Kevin Crowe >>>>> =20 >>>>> 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 lib= c, >>> 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 containi= ng >>> directory write allow permission, which is rather different from w= hat >>> people expect in unix systems, and is against the NFSv4 specificat= ion, >>> even though it might be a better fit for Windows. >> This is Windows behavior and inconsistent with the rest of FreeBSD and= any=20 >> 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 peop= le >>> 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, verif= ied >>> by passing the regression tests. >> Agreed. >> >> What in FreeBSD was this patch supposed to solve in the first place? > Growing divergence from OpenZFS upstream. I am not advocating this > patch, but it would be good, if possible, to not revert it completely, > but block wrong behavior with some minimal ifdefs to make further ZFS > merges easier. Help would be appreciated. ;) >