From owner-svn-src-head@freebsd.org Tue Jun 21 09:36:31 2016 Return-Path: Delivered-To: svn-src-head@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 8F302AC5F63; Tue, 21 Jun 2016 09:36:31 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D4442872; Tue, 21 Jun 2016 09:36:31 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-lb0-x22b.google.com with SMTP id xp5so6898057lbb.0; Tue, 21 Jun 2016 02:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=jTKuvjRLStrRA/fOm9S/pzxjvaqa42lBkMxr+xPgxnc=; b=m5sucP3GAJezdEemHXLzYS3N0miLliynnjNokKYLiGwOZs7vcG24GzD/husg5doMzE EMz5OYgSXrWlxQhrbGSJg4OzV3e2YGdtR4Y6GgZNQpTflRDexRi9ggxJBYqYUeC3i3h2 jPfCiD6HbCg5KZVfG386k+pEZX49a/7vjq2MftN7njPpp3+c52xWBvV5h6Lf6B6ELOm8 0v1gS41CISNKOv+x0dbbTtleWxZiMWhWOgkfKFhzNKpctu5pJCqviXbxX7AM7DKHtdtD 70n2+vLHuMaDHGu7HOLQxp5PvvsTqvbb/QK8x7pOzOvrdIcwDZUfG3xfyfLX4cRZTnvo MxlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=jTKuvjRLStrRA/fOm9S/pzxjvaqa42lBkMxr+xPgxnc=; b=jrB7PsWIZAWTuHRBTQwiYPmbBryXL4bN/ZaLET9q4tPltgM7wOe7rQ72wC4y1Ry0t0 dqQofNRV/1hcs5UKmnlRjxPjQ6mCIdMIxE7bs0BDcAhGGnyYF21zzDOJQsojGxHec2Ub isRVpC2MN1MaEtaq+wUuvxHI8JXSIZ8MLYFlJgm031bMLtro1UKdefGF1DIjPWgV82V+ y6Xof6qTwyy0oDkLZjgdukp/0vZtFN/j39ky2roqL84K4in8cpOYuerpPsSeyvtA6C24 fis0hUtfuluyKtMd+1aST7I0qghkS7XxJNEFLWay+tJ4YS3/vHWXKm7T5Loyec9P0h4z xrQA== X-Gm-Message-State: ALyK8tLIJGmywPOAsbWTQuI4bGH/GuGle7jpCSj2CeM6Gnh/9/pUrfMFMM8ay89b2XJEZw== X-Received: by 10.194.235.4 with SMTP id ui4mr20092268wjc.23.1466501789081; Tue, 21 Jun 2016 02:36:29 -0700 (PDT) Received: from brick (acyt159.neoplus.adsl.tpnet.pl. [83.11.203.159]) by smtp.gmail.com with ESMTPSA id t67sm2093644wma.1.2016.06.21.02.36.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jun 2016 02:36:28 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 21 Jun 2016 11:36:24 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Alexander Motin Cc: Cy Schubert , Jan Beich , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r299448 - in head/sys/cddl/contrib/opensolaris: common/acl uts/common/fs/zfs uts/common/sys Message-ID: <20160621093624.GD80346@brick> Mail-Followup-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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49d3d34d-ba91-ebdf-497f-cbe1614bec53@FreeBSD.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 09:36:31 -0000 On 0619T1733, Alexander Motin wrote: > On 19.06.16 17:28, Cy Schubert wrote: > > In message <20160619080803.GA1638@brick>, Edward Tomasz > > =?utf-8?Q?Napiera=C5=82 > > a?= 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 directories > >> - and > >>>> some additional considerations > >>>> > >>>> Reviewed by: Gordon Ross > >>>> Reviewed by: Yuri Pankov > >>>> Author: Kevin Crowe > >>>> > >>>> 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? > > 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. ;) Our family just expanded, and thus I'm afraid I won't be able to help for the next few weeks. That's one of the reasons why I've suggested the backout for 11.0 - not a permanent "let's ignore this piece of code forever" backout, but a temporary one, for 11.0; we would then go back to the topic after the release.