LFS locks not enforced on server side (can push commit modifying a file locked by another user)

[ckuhlmann]

• Gitea version (or commit ref): 1.11.4
• Git version: 2.26.1.windows.1
• Operating system: Win7x64
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No (no LFS support)
  • Not relevant
• Log gist:

Description

Steps to reproduce:

1. Create a new gitea instance or use an existing one
2. Add an admin user to gitea with name lfs_admin and password LFS_admin1 and extract the attached scripts.zip to a convenient directory.
3. Modify the value of variable GITEAHOST in line 3 of s01_admin.sh (in attached zip) to match your gitea host name and save.
4. Run
   ./s01_admin.sh
   in a git bash.
   This creates two users (a_user, b_user) and gives a_user a repo a_lfs_test, to which b_user is added as collaborator with write permission
5. Modify the value of variable GITEAHOST in line 4 of s02_a_user.sh (in attached zip) to match your gitea host and save.
6. Run
   ./s02_a_user.sh
   in a git bash.
   This initializes the a_lfs_test repo in sub-folder a_repo and puts all *.png files as lockable under LFS control. A file img.png is created and initialized with the content of wiki.png. This file and .gitattributes are staged, commited and pushed. Afterwards, the img.png file is locked by a_user.
7. Modify the value of variable GITEAHOST in line 4 of s03_b_user.sh (in attached zip) to match your gitea host and save.
8. Run
   ./s03_b_user.sh
   in a git bash (perhaps on a different machine, the result is the same).
   This clones the a_lfs_test repo into subfolder b_repo and initializes LFS. Because .gitattributes is checked out, LFS and locks are enabled for .png files. img.png is force overwritten by the contents of dice.png, staged, committed and pushed.
9. Observe the following output after running ./s03_b_user.sh in the previous step:

$ ./s03_b_user.sh
Cloning into 'b_repo'...
[...]
'../dice.png' -> './img.png'
[...]
[master d78418b] img->dice
 1 file changed, 2 insertions(+), 2 deletions(-)
Locking support detected on remote "origin". Consider enabling it with:
  $ git config lfs.http://b_user:B_user1,@localhost:88/a_user/a_lfs_test.git/info/lfs.locksverify true
Unable to push locked files:(1/1), 48 KB | 0 B/s
* img.png - A_User (refs: master)
WARNING: The above files would have halted this push.
Uploading LFS objects: 100% (1/1), 48 KB | 0 B/s, done.
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 355 bytes | 355.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: . Processing 1 references
remote: Processed 1 references in total
To http://localhost:88/a_user/a_lfs_test.git
   2e229ad..d78418b  master -> master
img.png A_User  ID:2

10. Although a message Unable to push locked files:(1/1) is returned, only a warning WARNING: The above files would have halted this push. results and the push succeeds 2e229ad..d78418b master -> master even though the lock of a_user persists (git lfs locks -> img.png A_User ID:2)
11. The result is also visible by opening img.png in the gitea UI: It shows the lock of a_user, but the content of dice.png pushed by b_user.

Expected result:
The push by b_user should be rejected (at least through a gitea configuration option), because a_user still holds a lock on img.png

Actual Result:
The push succeeds and the locked file img.png is modified by b_user

Requested change:
Please add a gitea configuration setting (either global or even better per repo) to reject such pushes on the server side, since otherwise locks are meaningless if the default client configuration is used. This leaves locks totally up to correct client configuration, which is error prone and negates the "protection" that locks should offer.

Thanks for gitea and for considering this request.

scripts.zip

[Eric-Li-376192056]

I met this problem too, please consider this request.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.

[eNBeWe]

Just ran into this issue.
I assumed that locked files would indeed be handled as locked as was very surprised when gitea just accepted the push.
Anything left to be done? Can anyone support to get this feature?

[jhgryder]

I am also experiencing this issue with Gitea version 1.13.2 and Git LFS version 2.13.2. Is there any plan to fix Gitea to enforce LFS locking?

[PostPollux]

Having the same problem with Gitea 1.15.0. Would be nice to see this in a future release!

[lunny]

Maybe we need check the lock in the function https://github.com/go-gitea/gitea/blob/v1.15.0/services/lfs/server.go#L253

[markusstephanides]

Bump. What is the point of having locks if they are not enforced? Or am I missing something?