x/net/webdav: fails when listing a directory with subdirs that cannot be read #43782
Labels
Milestone
Comments
|
Given the existence of #16195, I suspect there are is general class of issues when performing directory listings: things the server cannot recurse into, but which should not cause a failure. In particular, I think that if the server wouldn't normally be able to access a file or directory, that file or directory should either not be displayed in the response to PROPFIND, or it should be displayed, but not recursed into further (if that's even an option). If a user tries to access a file which the service cannot, return an appropriate error then, but do not block the service from working at all simply because a single file or directory within the share is broken. That just makes it far too fragile. |
seankhliao
added
the
NeedsInvestigation
|
I've read the RFC a bit more closely, and it looks like the proper solution may be to indicate the failure in the propstat elements. In particular, note http://www.webdav.org/specs/rfc4918.html#rfc.section.9.1.p.8 and http://www.webdav.org/specs/rfc4918.html#rfc.section.9.1.2.p.4 I think that implies that if the file is simply unreadable (e.g. a broken link) it should be skipped, and if it is there, but the server does not has permission, it should return a 403 for that particular element. |
klarose
added a commit
to Agilicus/golang-net
that referenced
this issue
Jan 20, 2021
PROPFIND can walk through directories, retrieving information about each file. Unfortunately, the filesystem may deny access to the WebDAV server for various reasons, such as the file truly not being readable (e.g. a broken symlink), or because the server does not have permission to read the file. PROPFIND should ignore these. The current behaviour of the WebDAV server when encountering such issues is to immediately stop its walk, and output an http 500. This leads to poor behaviour with the builtin golang server, since the walk has likely already written out its status header as part of serving the previously walked files' properties. The server closes the response, also emitting an error log. While the error log is noisy, the closed response is truly an issue: the xml returned to the client is invalid, which means that the response is useless. It is not unreasonable to expect that a directory shared using WebDAV has files which cannot be read for the reasons given above. The shared directory becomes useless with the current behavior. Rather than making directories with unreadable files useless, skip over anything that is bad. A more nuanced solution to this problem could likely involve indicating that the requested properties have problems, or buffering the response prior to returning the failure. However, this change is simple and a move in the right direction. Fixes golang/go#16195 Fixes golang/go#43782
|
Change https://golang.org/cl/285752 mentions this issue: |
heimoshuiyu
pushed a commit
to heimoshuiyu/net
that referenced
this issue
Aug 13, 2022
PROPFIND can walk through directories, retrieving information about each file. Unfortunately, the filesystem may deny access to the WebDAV server for various reasons, such as the file truly not being readable (e.g. a broken symlink), or because the server does not have permission to read the file. PROPFIND should ignore these. The current behaviour of the WebDAV server when encountering such issues is to immediately stop its walk, and output an http 500. This leads to poor behaviour with the builtin golang server, since the walk has likely already written out its status header as part of serving the previously walked files' properties. The server closes the response, also emitting an error log. While the error log is noisy, the closed response is truly an issue: the xml returned to the client is invalid, which means that the response is useless. It is not unreasonable to expect that a directory shared using WebDAV has files which cannot be read for the reasons given above. The shared directory becomes useless with the current behavior. Rather than making directories with unreadable files useless, skip over anything that is bad. A more nuanced solution to this problem could likely involve indicating that the requested properties have problems, or buffering the response prior to returning the failure. However, this change is simple and a move in the right direction. Fixes golang/go#16195 Fixes golang/go#43782
dmitshur
added
NeedsFix
WeiminShang
pushed a commit
to WeiminShang/net
that referenced
this issue
Nov 16, 2022
PROPFIND can walk through directories, retrieving information about each file. Unfortunately, the filesystem may deny access to the WebDAV server for various reasons, such as the file truly not being readable (e.g. a broken symlink), or because the server does not have permission to read the file. PROPFIND should ignore these. The current behaviour of the WebDAV server when encountering such issues is to immediately stop its walk, and output an http 500. This leads to poor behaviour with the builtin golang server, since the walk has likely already written out its status header as part of serving the previously walked files' properties. The server closes the response, also emitting an error log. While the error log is noisy, the closed response is truly an issue: the xml returned to the client is invalid, which means that the response is useless. It is not unreasonable to expect that a directory shared using WebDAV has files which cannot be read for the reasons given above. The shared directory becomes useless with the current behavior. Rather than making directories with unreadable files useless, skip over anything that is bad. A more nuanced solution to this problem could likely involve indicating that the requested properties have problems, or buffering the response prior to returning the failure. However, this change is simple and a move in the right direction. Fixes golang/go#16195 Fixes golang/go#43782 Change-Id: I065e4c90f7ef797709e5e81e7318c3eafae6db71 GitHub-Last-Rev: d56917e02885fb4151c0d6d8303be3e70dd4aa7a GitHub-Pull-Request: golang/net#91 Reviewed-on: https://go-review.googlesource.com/c/net/+/285752 Reviewed-by: Nigel Tao <nigeltao@golang.org> Reviewed-by: Nigel Tao (INACTIVE; USE @golang.org INSTEAD) <nigeltao@google.com> Run-TryBot: Nigel Tao <nigeltao@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Matthew Holt <matthew.holt@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
I assume so, since the code in question hasn't changed.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Exposed a webdav fileshare from /tmp, which has a few directories for which I do not have permission. E.g. in my case it's something like this:
I mounted it with the davfs2 filesystem for linux.
What did you expect to see?
I expect to see listed all files/subdirectories that the server is allowed to access. Failing that, I do not expect to see a failed transaction with a 'success' response code.
What did you see instead?
When mounting the service:
From the server:
Tracing shows that failure is when handling the initial PROPFIND. The webdav server tries to open a file for which it does not have permission, and it fails. However, it fails after already writing content and returning a response code of 207. The error returned is "Error open /tmp/tel-XXXXXXX: permission denied".
The text was updated successfully, but these errors were encountered: