[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Unexpected behavior with path-based permissions

From: <devnullaccount_at_yahoo.se>
Date: Wed, 29 May 2019 09:03:00 +0000 (UTC)

Hi,
we're using the path-based authorization to avoid costly mistakes when someone accidentally deletes things they shouldn't, but we just had an incident anyway and I can't get my head around how this was possible. I'll outline our settings below if anyone can figure out if we have it wrong, if the server someone did something unexpected or if I simply misunderstand the configuration file syntax.

We have a layout of
/project1/{trunk,branches}

And to prevent that someone accidentally deletes the trunk or branches or adds branches in the root of "project1", we have this in our access file ("admins" is a group containing only a few users):

[/]
@members = r
@admins = rw

[/project1]

@members = r
@admins = rw

[/project1/branches]

@members = rw

The latter so that people can create new directories under "/project1/branches/", but I did not think that would give them permission to delete "/project1/branches", which is exactly what someone managed to do. Is this expected behavior based on the above configuration? I thought that the "r" setting for "project1" would mean that a write that deletes a file/directory immediately under that one would be disallowed. We have verified that no one can add a file directly under /project1/ so then I can only think that the rw on /project1/branches allows delete of that directory while I thought that it would only allow rw below that one (i.e. branches/*)

If this is expected behavior, how can I differentiate permission between "project1/branches" and "project1/branches/*"? That is, I want to prevent anyone from deleting "branches", but I want to allow them to add filer under "branches/"

TIA,
  Chris
Received on 2019-05-29 11:03:21 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.