Limited subdirectory access handled differently

[trentfisher]

I know this is a weird case, imagine an authz file like this:

[/]
somebody = rw
[/branches/a]
tfisher = r

In v2.3.3 when I access websvn it will list this repository on the repository list and I can navigate in directly, though it shows me nothing other than /branches/a (that is, / only contains "branches" and /branches only contains "a")

But in v2.5 it omits the repository from the repository list and attempting to access /branches (by doctoring the URL) yields "You do not have the necessary permissions to view this content." But if I doctor the URL to access /branches/a, it works fine.

To be honest, the new behavior makes sense since it just reflects what svnauthz reports, but it is causing a lot of wailing amongst my user base. So I need to figure out how to revert to the old behavior. I will try to dig into the source code to fix this, but any assistance would be welcome.

[michael-o]

Looking forward too. This may be related also the the -R switch...

[ams-tschoening]

Regarding my tests, -R won't change anything here. It seems to check if requested access on requested path is fulfilled by ALL subdirs in the requested path as well. That is different from the former implementation used by WebSVN, in which access to ANY subdir of the requested path was enough to allow access to the path itself. Look at the following example:

[/]
nobody = r

[/branches/a]
tschoening = r

[/branches/a/b]
tschoening =

The following returns success:

C:\[...]>svnauthz accessof "C:\[...]\authz_websvn" --username=tschoening --path=/branches/a
r

While the following doesn't:

C:\[...]>svnauthz accessof "C:\[...]\authz_websvn" --username=tschoening --path=/branches/a -R
no

The following is the old implementation and where it has been used:

if ($checkSubFolders) {

https://github.com/websvnphp/websvn/blob/2.3/include/auth.php#L152

// Only list files/directories that are not designated as off-limits
$access = ($isDir) ? $rep->hasReadAccess($path.$file, true)
                             : $accessToThisDir;

https://github.com/websvnphp/websvn/blob/2.3/listing.php#L109

I don't see how the old behaviour can be restored without parsing authz manually again: The old implementation is only fast because of access to all sections of authz. The only workaround possible now would be to iterate ALL subdirs of a dir of interest and check if ANY of those can be seen by the user to decide that the parent is visible as well. That's what the former implementation actually does by checking all sections of authz. That's going to be complicated and slow and stuff, especially in the root dirs of repos.

@trentfisher Is changing your authz to provide read access to folders you need to navigate not an option? That's what all file system explorers would expect as well. The former implementation seems to be pretty non-standard to me.

[neeral85]

Even toplevel folder are not shown. user2 in the example below can't see /tags in websvn

[/] *=r user1 = r

[/branches/] *= admin=rw

[/tags/] user2 =r

#svnauthz accessof "C:\[...]\authz_websvn" --username=user2 --path=/tags/
r

In contrast to the behavior above at least this is inconsistent with apache (mod_dav_svn) and does not follow the AuthzSVNAccessFile Guidelines

[ams-tschoening]

Guten Tag neeral85, am Montag, 8. Juli 2019 um 10:46 schrieben Sie:

Even toplevel folder are not shown. user2 in the example can't see /tags in websvn

Are you sure you are using the exact same auth-file in both cases? Because when I copy 1:1 what you have provided as example, I get the following error messages:

svnauthz: E220003: Error while parsing authz file: 'authz_websvn_ghi': svnauthz: E220003: Non-canonical path '/branches/' in authz rule [/branches/] svnauthz: E220003: Found empty name in authz rule path

I need to remove the "/" at the end of "branches" and "tags" to make things working and get "r" as the result in the shell. In case of two different files, this might easily explain why WebSVN doesn't allow access.

If that is not the problem, I'm afraid you must debug further on where exactly access is denied wrongly under which circumstances.

Mit freundlichen Grüßen,

Thorsten Schöning

-- Thorsten Schöning E-Mail: [email protected] AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[neeral85]

sorry, that's my mistake as I extracted the example from my working copy. The correct authz does not contain tailing slash after the folder name. However, it themes that there are additional lines required to reproduce this issue

[/]
*=r

[/branches]
*=
admin=rw

[/tags]
user2 =r

# /tags/a may not exist. however, it required to be configured to reproduce the issue.
[/tags/a]
*=
admin=rw

Now /tags does not show up for user2 in websvn.

#svnauthz accessof "C:\[...]\authz_websvn" --username=user2 --path=/tags/
r

[ams-tschoening]

Guten Tag neeral85, am Montag, 8. Juli 2019 um 15:12 schrieben Sie:

/tags/a may not exist. however, it required to be configured to reproduce the issue.

[/tags/a] *= admin=rw

Now /tags does not show up for user2 in websvn.

Doesn't make much sense to me: How can a non-existing directory WebSVN doesn't know a thing about influence access checks? Please provide more details about how exactly your repo looks like, what gets shown in WebSVN when, what you need to click to not see some dirs anymore with which user etc.

Afterwards you can debug this further, especially looking at the file include/authz.php and the function "hasReadAccess". Simply add some debug statements to see where that function goes and how it gets called. The results can be found in the error logs of your web server.

https://www.php.net/manual/de/function.var-dump.php

Mit freundlichen Grüßen,

Thorsten Schöning

-- Thorsten Schöning E-Mail: [email protected] AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[neeral85]

tested now with ubuntu 18.4:

#svnauthz accessof '[...]/authz_websvn' --username=user2 --path=/tags/
r

WebSVN generates:

svnauthz accessof --repository test --path '/tags/' --username 'user2' -R '[...]/authz_websvn'
no

if i run it without option -R:

svnauthz accessof --repository test --path '/tags/' --username 'user2' '[...]/authz_websvn'
r

i did not found man for svnauthz, so I've no idea what "-R" means.

[michael-o]

-R [--recursive] : determine recursive access to PATH

From svnauthz h accessof

[ams-tschoening]

Guten Tag neeral85, am Montag, 8. Juli 2019 um 16:52 schrieben Sie:

WebSVN generates:

svnauthz accessof --repository test --path '/tags/' --username 'user2' -R '[...]/authz_websvn'
no

There seems to be only one place where -R comes into play in listing directories in listing.php:

// Only list files/directories that are not designated as off-limits $access = ($isDir) ? $rep->hasReadAccess($path.$file, true) : $accessToThisDir;

Looking at the history of that code, the behaviour is like that for quite some time already and has only been refactored. I wonder what's the purpose of looking into children at that point? Might have to do with download links rendered as well.

@neeral85, change "true" to "false" and see what happens, if things start to work for you. Most likely they do, than please additionally test how downloads behave, if those links are rendered and can be executed and what gets downloaded and stuff like that.

Mit freundlichen Grüßen,

Thorsten Schöning

-- Thorsten Schöning E-Mail: [email protected] AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[neeral85]

@neeral85, change "true" to "false" and see what happens, if things start to work for you. Most likely they do, than please additionally test how downloads behave, if those links are rendered and can be executed and what gets downloaded and stuff like that.

I've done that and couldn't see that issue anymore. Everything I've tested (downloading, sub-folder, ..) was working well, so this may come in the next release...?

[ams-tschoening]

Guten Tag neeral85, am Montag, 8. Juli 2019 um 20:07 schrieben Sie:

I've done that and couldn't see that issue anymore. Everything I've tested (downloading, sub-folder, ..) was working well[...]

Where exactly did you test downloading for which directory and user? Remember that you have acces restrictions in place, which should reflect the downloads, that's the whole point for test.

In your example, "user2" has no access to "/tags/a" and because of "-R" access checks fail even on parent directories. Without "-R" those access checks succeed until the point "user2" wants to access "/tags/a", which should fail again or that directory might not even be shown in the first place.

But what happens in case of downloading "/tags" by "user2"? I have the feeling that's why "-R" has been implemented in the first case, so that people can't see things they are not allowed to download as well or stuff like that.

Mit freundlichen Grüßen,

Thorsten Schöning

-- Thorsten Schöning E-Mail: [email protected] AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[neeral85]

user2 does not even see /tags/a (I've created this especially for this test), so everything works as expected.

I assume -R was implemented in svnauthz to know if the user can access the full sub-tree because of that behavior: http://svnbook.red-bean.com/en/1.8/svn.serverconfig.pathbasedauthz.html#idm9032 (see: Some Gotchas with Access Control)

However, as far as I can see there is no need ever for WebSVN to use this option as you never need to know access for sub-folders. There is always a dedicated request for every folder/file in WebSVN.

[ams-tschoening]

Guten Tag neeral85, am Dienstag, 9. Juli 2019 um 08:43 schrieben Sie:

However, as far as I can see there is no need ever for WebSVN to use this option as you never need to know access for sub-folders. There is always a dedicated request for every folder/file in WebSVN.

Not for downloads: You can easily start a download for a directory tree at a level in which you can still see dirs, "/tags" in your case, while the download would contain dirs to which access is forbidden, "/tags/a" in your case. The download links don't seem to depend on individual access checks.

OTOH, doing the actual download DOES properly seem to recognize -R because of using the function "hasUnrestrictedReadAccess". So, "-R" must not be removed entirely, but instead we need to decide if the line using it in "listing.php" can be used without -R, by not providing "true" to the call.

Looking at the history, the line has been introduced with "true" for recursive checks right from the start, but I don't see any documented reason:

https://github.com/websvnphp/websvn/commit/adaa59f4c7149d748f2b4acafc5c69da3bb8df4b#diff-b7327c6d2d9e03285f57b2039cc45055

@neeral85

Please provide a PR simply changing "true" to "false" linking to your first comment with the problem here. We can think of this a bit more and most likely simply merge it at some point. Thanks!

Mit freundlichen Grüßen,

Thorsten Schöning

-- Thorsten Schöning E-Mail: [email protected] AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[rm5248]

Note: this is an issue with the following access file as well:

[/]
* =

[/path]
username = rw

When accessing /, a 500 error is sent back to the browser:

[Mon Apr 27 17:08:06.760447 2020] [php7:error] [pid 9604] [client xx.xx.xx.xx:50790] PHP Fatal error:  Uncaught Error: Call to a member function hasUsername() on null in /usr/share/websvn-sw/include/setup.php:568\nStack trace:\n#0 /usr/share/websvn-sw/index.php(107): checkSendingAuthHeader()\n#1 {main}\n  thrown in /usr/share/websvn-sw/include/setup.php on line 568

Accessing the repo directly via the URL does work(listing.php?repname=repo+name), however it says "You do not have the necessary permissions to view this content.".

I tried the fix in #89, and that didn't seem to fix anything; in fact it seems to cause it to stop working. I tried using 'svnauthz' from the command line, and no combination of options seems to make this work correctly.

It seems like this was all introduced in https://github.com/websvnphp/websvn/commit/60788a5b1e9d1b46fe5f583848d46ffb1dcab279, and it mostly works, but fails in these specific edge cases, so it seems to me like that commit needs to be reverted.

[michael-o]

The error message is confusing. I have removed all authentication code from WebSVN. Authn has to happen by webserver means. @rm5248 Can you retry from master?

[MosfetN]

Hello, I have the same error with version 2.7.0 Here is my authz file:

[groups]
admin = other_user
project = user1

[Project:/]
@admin = rw
[Project:/Folder1]
@project = r

user1 can't see Project repo in WebSVN and he gets an auth error when accessing to https://websvn/browse/Project? (he can access to https://websvn/browse/Project/Folder1?) He can access to https://svn/Project and see the Project1 folder.

Do you have any fix for this please?

[MatReiKIT]

Hello, is there any progress on this issue? We got the same issue of no longer visible Repositorys like decribed in #188 or mentioned from @rm5248 after updating from 2.3.3 to 2.8.2

We have a lot of personal repos where only the owner has rw rights on the root folder and others have no rights. But subfolders are shared with others by setting explicit rights.

I think the problem can be found of the usage of svnauthz. Like already mentioned svnauthz accessof returns no access of the root folder, but correct rights if you enter the full path. The -R (recursive) flag does no difference in this case, because it checks if the user has full access to the path. Omitting the path and only providing the repository will return the maximum of definded rights for the user (declared in any subfolder). Maybe this can be helpfull.

Bests Mathias

[michael-o]

Hello, is there any progress on this issue? We got the same issue of no longer visible Repositorys like decribed in #188 or mentioned from @rm5248 after updating from 2.3.3 to 2.8.2

We have a lot of personal repos where only the owner has rw rights on the root folder and others have no rights. But subfolders are shared with others by setting explicit rights.

I think the problem can be found of the usage of svnauthz. Like already mentioned svnauthz accessof returns no access of the root folder, but correct rights if you enter the full path. The -R (recursive) flag does no difference in this case, because it checks if the user has full access to the path. Omitting the path and only providing the repository will return the maximum of definded rights for the user (declared in any subfolder). Maybe this can be helpfull.

Bests Mathias

Unfortunately not, but I think the best approach is to call the decision logic from Subversion with C (C lib to PHP shim, like the Apache module does) instead of reimplementing and tracking every new release.