Re: svn authz error: Access denied issue when running svn rm resource where the user should be able to have full access

[dev@: tl;dr: mod_authz_svn shouldn't require svn_authz_recursive access
on DELETE when the target is a file]

Andrei Cusnir wrote on Wed, Jul 21, 2021 at 21:58:04 +0200:
> Hi,
> here is my authz config file
> 
> [groups]
> r_users =  Alexander_Lost
> 
> [:glob:/]
> * = rw
> 
> [:glob:/**/*.uasset]
> @r_users = rw
> 
> [:glob:/**/Source/**]
> @r_users =
> 
> 
> user Alexander_Lost should be able to work with uasset type of files and
> should not see anything that has Source in the global path
> 
> when i am trying to remove a path
> svn rm https://"Alexander_Lost"@
> subversion.assembla.com/svn/repo_name/branches/project_name/Projects/ShooterGame/Content/Mods/project_name/Assets/Foliage/Trees/StepeeGrass/Grass01/skwnorp_2K_Normal.uasset
> -m "test uasset delete by andrei"
> svn: E175013: Access to
> '/svn/repo_name/!svn/txr/153436-3cur/branches/project_name/Projects/ShooterGame/Content/Mods/project_name/Assets/Foliage/Trees/StepeeGrass/Grass01/skwnorp_2K_Normal.uasset'
> forbidden
> 
> in apache logs i can see the following
> 
> [Wed Jul 21 19:47:42.187161 2021] [authz_svn:error] [pid 1510:tid
> 140015597156096] [client 188.26.223.19:42966] Access denied:
> 'Alexander_Lost' DELETE
> repo_name:/branches/project_name/Projects/ShooterGame/Content/Mods/project_name/Assets/Foliage/Trees/StepeeGrass/Grass01/skwnorp_2K_Normal.uasset
> 
> 
> Please let me know if this is a config error or it is an authz bug.

What's the output of «svn info
^/branches/project_name/Projects/ShooterGame/Content/Mods/project_name/Assets/Foliage/Trees/StepeeGrass/Grass01/skwnorp_2K_Normal.uasset@HEAD»?
I'm looking for the Node Kind line.

With your authz file, I get:

    % svnauthz accessof /path/to/your/authz/file --username Alexander_Lost --path /branches/project_name/Projects/ShooterGame/Content/Mods/project_name/Assets/Foliage/Trees/StepeeGrass/Grass01/skwnorp_2K_Normal.uasset --repository repo_name
    rw
    % svnauthz accessof /path/to/your/authz/file --username Alexander_Lost --path /branches/project_name/Projects/ShooterGame/Content/Mods/project_name/Assets/Foliage/Trees/StepeeGrass/Grass01/skwnorp_2K_Normal.uasset --repository repo_name -R
    no

The authz functionality doesn't deal in revision numbers.  That implies
it doesn't deal in node kinds either (since node kinds can't be
determined without resolving a node's path at a particular revision (or
transaction)).  That, in turn, means authz must treat /foo/bar/baz.asset
as something that, for all it knows, might be a directory (at least in
some historical revisions).  Therefore, as soon as there's a a glob rule
that might apply to at least one descendant of /foo/bar/baz.asset, and
that would grant Alexander_Lost "" (aka "no") access, the answer to the
recursive access check ought to become "no".  I think that's what
explains the svnauthz(1) results above.

Now, the delete logic should request a *non* recursive access check if
the thing to be deleted is a plain file in HEAD.  subversion/libsvn_repos/commit.c:delete_entry()
does behave this way — when the .uasset path identifies a non-directory
in HEAD, which is why I asked about that above — but if I'm reading
mod_authz_svn's code correctly, it requires svn_authz_recursive access
on all DELETE calls, regardless of whether a file or a directory is
being requested to be deleted.

Which is to say, this would seem to be a bug in mod_authz_svn.

Cheers,

Daniel