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.

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

x/net/webdav: delete should release locks #42839

Open
klarose opened this issue Nov 25, 2020 · 3 comments · May be fixed by golang/net#92
Open

x/net/webdav: delete should release locks #42839

klarose opened this issue Nov 25, 2020 · 3 comments · May be fixed by golang/net#92
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@klarose
Copy link

klarose commented Nov 25, 2020

What version of Go are you using (go version)?

go version go1.15 linux/amd64

Does this issue reproduce with the latest release?

I haven't tried yet, but the relevant code does not seem to have changed.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/kyle/.cache/go-build"
GOENV="/home/kyle/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/kyle/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/kyle/"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build077298422=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I'm using https://github.com/hacdias/webdav to evaluate a few things. I plan on implementing my own server using the webdav library soon, but wanted to get some testing done on it before diving in. While testing (using davfs2 as a client), I noticed that if I did the following, the third operation would always fail.

touch foo.txt && rm foo.txt && touch foo.txt
touch: cannot touch 'foo.txt': Permission denied

The requests/responses issued by davfs2/returned by webdav are:

  1. PROPFIND / -> 207
  2. LOCK foo.txt -> 201
  3. HEAD /foo.txt -> 200
  4. DELETE /foo.txt -> 204
  5. LOCK /foo.txt -> 423
  6. PROFIND /foo.txt -> 404

If I wait for a bit between when I create the file and delete it, everything works fine. It looks to me like davfs2 creates the lock, but does not flush the contents of the file/release the lock until some time expires. If I remove the file before that time expires, davfs2 issues the DELETE without releasing the lock. The problem is that despite the file not existing, the webdav server still thinks that a lock is present for the file, so it refuses to lock it again in step 5.

Perhaps davfs2 should release the lock. But, the webdav RFC is pretty clear that the lock should be released when the file is deleted:

   A server processing a successful DELETE request:

   MUST destroy locks rooted on the deleted resource

Detailed reproduction steps:

  1. Compile https://github.com/hacdias/webdav
  2. Run the following:
cd $(mktemp -d)
cat > config.yaml <<EOF 
# Server related settings
address: 127.0.0.1
port: 8080
auth: false
tls: false
prefix: /

scope: .
modify: true
rules: []
EOF

webdav -p 8080 --auth=false
  1. Download/build/install/etc cadaver
  2. Run cadaver http://localhost:8080
  3. In its command prompt, run the following commands:
lock foo.txt
rm foo.txt
lock foo.txt
  1. Note that the third operation fails with 423 Locked. It should have succeeded.

What did you expect to see?

dav:/> lock foo.txt
Locking `foo.txt': succeeded.
dav:/> rm foo.txt
Deleting `foo.txt': succeeded.
dav:/> lock foo.txt
Locking `foo.txt': succeeded.
dav:/> 

What did you see instead?

dav:/> lock foo.txt
Locking `foo.txt': succeeded.
dav:/> rm foo.txt
Deleting `foo.txt': succeeded.
dav:/> lock foo.txt
Locking `foo.txt': failed:
423 Locked
dav:/> 
@gopherbot gopherbot added this to the Unreleased milestone Nov 25, 2020
@networkimprov
Copy link

cc @ianlancetaylor

Seems overlooked by triage?

@toothrot toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 8, 2020
klarose added a commit to Agilicus/golang-net that referenced this issue Jan 21, 2021
The WebDAV RFC indicates that locks rooted on deleted resource MUST be
destroyed. The WebDAV server does not do this with the builtin in-memory
lock system (memLS). This commit adds a new interface, implemented by
memLS, which allows for deleting locks rooted at a given resource.

We added a new interface rather than extending or changing the existing
one to avoid breaking backwards compatibility with other implementations
of the LockSystem interface. The WebDAV server will behave as it used to
if using a LockSystem which has not implemented the new interface.

We apply the same operation for moved files. This follows from the
WebDAV RFC which indicates that a move is logically a copy followed by
consitency checks, followed by a delete of the source.

Fixes golang/go#42839
@klarose
Copy link
Author

klarose commented Jan 21, 2021

I have a potential fix for this. Going to wait for my CLA to go through, but feel free to take a look.

@klarose klarose linked a pull request Jan 22, 2021 that will close this issue
@gopherbot
Copy link

Change https://golang.org/cl/285753 mentions this issue: webdav: release locks when deleting

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants