Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jun 2016 08:39:55 -0700
From:      Adrian Chadd <adrian.chadd@gmail.com>
To:        Alexander Motin <mav@freebsd.org>, Cy Schubert <Cy.Schubert@komquats.com>,  Jan Beich <jbeich@vfemail.net>,  "src-committers@freebsd.org" <src-committers@freebsd.org>,  "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>,  "svn-src-head@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:  <CAJ-Vmon-gQZwG-9mcFP1kNmWHDNSfmbE5GSjrpDGwXTKaHSZRw@mail.gmail.com>
In-Reply-To: <20160621093624.GD80346@brick>
References:  <201606191428.u5JESbbs053857@slippy.cwsent.com> <49d3d34d-ba91-ebdf-497f-cbe1614bec53@FreeBSD.org> <20160621093624.GD80346@brick>

next in thread | previous in thread | raw e-mail | index | archive | help
"Solution dictated on account of personal life" is totally legit!


-a


On 21 June 2016 at 02:36, Edward Tomasz Napiera=C5=82a <trasz@freebsd.org> =
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 <mav@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 direct=
ories
>> >> - and
>> >>>>   some additional considerations
>> >>>>
>> >>>>   Reviewed by: Gordon Ross <gwr@nexenta.com>
>> >>>>   Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com>
>> >>>>   Author: Kevin Crowe <kevin.crowe@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 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.
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon-gQZwG-9mcFP1kNmWHDNSfmbE5GSjrpDGwXTKaHSZRw>