From owner-svn-src-all@freebsd.org Tue Jun 21 15:39:56 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 EE7B4AC511B; Tue, 21 Jun 2016 15:39:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 B5B1E275B; Tue, 21 Jun 2016 15:39:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id g127so21327444ith.0; Tue, 21 Jun 2016 08:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=UtQNlua9UtO3a+yWUvyYdZvxAgu+RcMPkGG57uLtyqA=; b=BjPt5meYcd62QnSut5/wYEZWpGcPrMXHaTpzLX9idtIF+Xxv1Qe6n6fP0OmmOiv8om uHO2MHF0kfzgJQ5v7j3u4nDxxIMjyeeEkeVXNXINWVDY5cOrvI95dZpmf70sKRQk47Np ROJrx9WCtsZ4d9miTVtwnsk2HrKgsmz8KuF7Ueo0XJD4MHKLXmPNhuwKZmAtwuyWqwVX n9lFZ74AgLTN6jcdzP0O/6vpCorsGyARWKJxdO8v/b08mPCICpiJtWgI5v72dcEBgffs 3ysQmoOMWyH8sWEDKHBPoeDqq4pqT7CmndTfhFzCydzfH0/Lf1qwwcCkJVALVP8ze2vn fJqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=UtQNlua9UtO3a+yWUvyYdZvxAgu+RcMPkGG57uLtyqA=; b=mEuL9KAusHyAhdYCsVwvsKX7Qf05KJbEdDJB4SfzqsH9MlhDCT+JgH6dK7OVAm4QTY cemjEwNkuQ3cW8Ryi+NNBUq0KE9LgddM4N/fdJyMA3/Gz9qDeTG+0CbUL8rk9SaU+lPs /I/2FS/SpxEcu5k65F45IrF1QvmqQZGBe9jh+3/RU382QFYDZNk3agx/v3gbJvdN2b7B GWkMeBpD0Zg2lAqG/Pj/9V5uj2qYqS/IOpL7GMr4VYyXpr/n5vvZ9Wv1qx9F3I5CJ56e KXOts2nT/Fp51cWFLr6zEPat89noUslH2qpnD98c9QhCcYnQUo4V5gJYAtmE0Y02p/pT uxzw== X-Gm-Message-State: ALyK8tIWmy1WJK9+lfahvjRUhz699uQkPCs+qLr5ov0skQ928OHRMrEga4uflYPYhF+R3J+muWCwSbwqB6QURg== X-Received: by 10.36.250.10 with SMTP id v10mr6434473ith.25.1466523595883; Tue, 21 Jun 2016 08:39:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.210.212 with HTTP; Tue, 21 Jun 2016 08:39:55 -0700 (PDT) In-Reply-To: <20160621093624.GD80346@brick> References: <201606191428.u5JESbbs053857@slippy.cwsent.com> <49d3d34d-ba91-ebdf-497f-cbe1614bec53@FreeBSD.org> <20160621093624.GD80346@brick> From: Adrian Chadd Date: Tue, 21 Jun 2016 08:39:55 -0700 Message-ID: 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" Content-Type: text/plain; charset=UTF-8 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: Tue, 21 Jun 2016 15:39:57 -0000 "Solution dictated on account of personal life" is totally legit! -a On 21 June 2016 at 02:36, Edward Tomasz Napiera=C5=82a = wrote: > On 0619T1733, Alexander Motin wrote: >> On 19.06.16 17:28, Cy Schubert wrote: >> > In message <20160619080803.GA1638@brick>, Edward Tomasz >> > =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 >> >> - 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 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 >> > 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. ;) > > 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. > >