Re: Permissions need for deletion

On 8/25/2016 11:52 AM, Stefan Hett wrote:
> On 8/25/2016 11:35 AM, Ivan Zhakov wrote:
>> On 25 August 2016 at 12:30, Stefan Hett <stefan_at_egosoft.com> wrote:
>>> On 8/25/2016 11:13 AM, Ivan Zhakov wrote:
>>>> On 25 August 2016 at 11:50, Vacelet, Manuel
>>>> <manuel.vacelet_at_enalean.com>
>>>> wrote:
>>>>> On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
>>>>> <manuel.vacelet_at_enalean.com> wrote:
>>>>>> oops I hit shift+enter :/
>>>>>> see my message below
>>>>>>
>>>>>> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
>>>>>> <manuel.vacelet_at_enalean.com> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I got a machine that was bumped from 1.6.x (centos6 default) to
>>>>>>> 1.8.16
>>>>>>> (thanks wandisco!).
>>>>>>> I identified a change of behaviour but failed to find an
>>>>>>> explanation in
>>>>>>> book or change log.
>>>>>>>
>>>>>>> Here we go, given a SVNAccessFile like:
>>>>>>
>>>>>> ------------->8-------------
>>>>>> [groups]
>>>>>> members = alice
>>>>>> admin = bob
>>>>>>
>>>>>> [/]
>>>>>> * =
>>>>>> @members = r
>>>>>> @admin = rw
>>>>>>
>>>>>> [/tags]
>>>>>> @members = rw
>>>>>> -------------8<-------------
>>>>>>
>>>>>> WIth svn 1.6, as alice, I cannot rm /tags
>>>>>> Whereas with svn 1.8 I now can.
>>>>>>
>>>>>> Is this detailed somewhere ?
>>>>>
>>>>> Fun fact: the behaviour change also depending on the version of svn
>>>>> client
>>>>> used.
>>>>> For a given svn 1.8 server, I can delete /tags with svn 1.7, 1.8 &
>>>>> svn
>>>>> 1.9
>>>>> client but not with svn 1.6.
>>>>> I failed to find in 1.7 release note something that explains this
>>>>> change.
>>>>>
>>>> It was bug in Subversion 1.7 that remove operation requires access to
>>>> repository root:
>>>> SVN-4219: svn delete fails with "403 Forbidden" if root is not
>>>> readable
>>>> [1]
>>>>
>>>> This problem was fixed in Subversion 1.8. It's not server-side change.
>>>> It was client problem accessing repository root, while it's not
>>>> needed.
>>>>
>>>> [1] https://issues.apache.org/jira/browse/SVN-4219
>>> According to SVN-4219 the issue was present in 1.7 and also fixed in
>>> 1.7, or
>>> is the JIRA issue record wrong in this regards?
>>> Also I take it that with Manuel's report here, the issue was not only
>>> present in 1.7 but also existed on 1.6. Otherwise I think I'm missing
>>> something.
>>>
>> The SVN-4219 is duplicate issue for SVN-4332.
> Right, but what gets me confused there is that SVN-4332 explicitly
> states: "The 1.6/neon client can delete /A/B [...] but the 1.7/neon
> client fails[...]". That suggests to me the issue wouldn't be present
> with 1.6 but only with 1.7.0-1.7.9.
> This would be contradicting to the OP report that removing the file is
> possible with his 1.6 client.
Of cause this should read: "[...] OP's report that removing the file is
*NOT* possible with his 1.6 client.
>
> I take it, it's not worth continuing checking the history here, since
> the unquestionable conclusion is is that the behavior the OP sees in
> 1.7+ is the correct one by design (aka: having write access to a path
> allows also to delete that path - FWIW: That's not quite what I'd
> expect, since I would assume that I also need write access to the
> parent path in order to remove a directory/path since that's also the
> access I require to create that directory/path).
>

-- 
Regards,
Stefan Hett