Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Limited subdirectory access handled differently #85

Open
trentfisher opened this issue Jun 4, 2019 · 18 comments
Open

Limited subdirectory access handled differently #85

trentfisher opened this issue Jun 4, 2019 · 18 comments

Comments

@trentfisher
Copy link

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
Copy link
Member

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

@ams-tschoening
Copy link
Contributor

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.

@ams-tschoening ams-tschoening mentioned this issue Jul 4, 2019
Closed
@neeral85
Copy link

neeral85 commented Jul 8, 2019 •
edited
Loading

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
Copy link
Contributor

ams-tschoening commented Jul 8, 2019 via email

@neeral85
Copy link

neeral85 commented Jul 8, 2019

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
Copy link
Contributor

ams-tschoening commented Jul 8, 2019 via email

@neeral85
Copy link

neeral85 commented Jul 8, 2019

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
Copy link
Member

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

From svnauthz h accessof

@ams-tschoening
Copy link
Contributor

ams-tschoening commented Jul 8, 2019 via email

@neeral85
Copy link

neeral85 commented Jul 8, 2019

@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
Copy link
Contributor

ams-tschoening commented Jul 9, 2019 via email

@neeral85
Copy link

neeral85 commented Jul 9, 2019

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
Copy link
Contributor

ams-tschoening commented Jul 9, 2019 via email

ams-tschoening added a commit that referenced this issue Jul 14, 2019
@ams-tschoening
#85 mentiones a problem in which top level directories are not shown …
2213260 
…anymore in case of access to their subdirs is restricted for the current user. Reason is a recursive check of access to subdirs when their parent should be shown, for which nobody seems to know the reason currently. This commit reverts that behaviour.

#85 (comment)
@ams-tschoening ams-tschoening mentioned this issue Jul 14, 2019
Merged
ams-tschoening added a commit that referenced this issue Jul 23, 2019
@ams-tschoening
Show top level dirs in listing even without access to subdirs.
343b1af 
#85 mentions a problem in which top level directories are not shown anymore in case of access to their subdirs is restricted for the current user. Reason is a recursive check of access to subdirs when their parent should be shown, for which nobody seems to know the reason currently. This commit reverts that behaviour.

#85 (comment)
#85 (comment)
@rm5248
Copy link

rm5248 commented Apr 27, 2020

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 60788a5, 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
Copy link
Member

michael-o commented Apr 27, 2020 •
edited
Loading

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
Copy link

MosfetN commented Apr 28, 2022

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?

@michael-o michael-o mentioned this issue Mar 20, 2023
Open
@MatReiKIT
Copy link

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@rm5248 @michael-o @trentfisher @ams-tschoening @MatReiKIT @neeral85 @MosfetN