nextcloud / nextcloud/files_lock

User can unlock file locked by other user in shared folders

Open
#169 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

0. Needs triage bug enhancement
Dominant language
JavaScript
Stars
39
Forks
10
Avg merge
1d 11h
Merged PRs (30d)
48

Description

Scenario:
User A creates a shared directory.
User B creates a file in that directory and locks the file
User A tries to unlock that file.

What happens:
The file gets unlocked without errors.

What should happen / is expected:
The file stays locked and the server returns 403. Because the lock is owned by user B.

Why does this happen
The initial test if the owner of the lock and the current user are the same, fails ✔️
https://github.com/nextcloud/files_lock/blob/7b1827af32b848b6ed25bcefc17696b9260a61f8/lib/Service/LockService.php#L244

But then the next check allows to unlock, because the file is created inside the shared directory it is owned implicitly by the sharing user, and we allow file owners always to unlock:
https://github.com/nextcloud/files_lock/blob/7b1827af32b848b6ed25bcefc17696b9260a61f8/lib/Service/LockService.php#L248


I am not sure if this is a feature or a bug. So probably two solutions here:

  1. Allow configure whether file owners are allowed to always unlock
  2. Document that file owners always can unlock their files and note that files in shared folders are always owned by the folder owner.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in lib/Service/LockService.php at the checks around lines 244 and 248, then trace the unlock request and its existing tests. Confirm how ownership is determined for files in shared directories and decide whether the intended behavior is a 403 response or a documented/configurable exception. Done means the chosen policy is covered by a regression test and the reported scenario behaves accordingly.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
authorization
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.