Mirror of gocryptfs source code on Github http://nuetzlich.net/cgit/gocryptfs/atom?h=LockSharedStorage 2024-12-05T20:16:33+00:00 2024-12-05T20:16:33+00:00 Jakob Unterwurzacher 2024-12-05T20:16:33+00:00 urn:sha1:fda035ba73b9b80979a069385e88c7b0bc8268db https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_dispatch 2023-06-19T11:35:29+00:00 Jakob Unterwurzacher 2023-06-19T11:35:29+00:00 urn:sha1:15d34762ab9f375b9aa738119aa7e2dd1497102e Complain loudly when the underlying storage does not support byte-range locks. https://github.com/rfjakob/gocryptfs/issues/754 2023-06-19T11:27:44+00:00 Jakob Unterwurzacher 2023-06-19T11:26:44+00:00 urn:sha1:a97df8508a3f9bfc6d398c152bf15c6fcd98c74b With -sharedstorage, when we get a decryption error, we lock the byte range and try again. This makes concurrent R/W safe agains torn writes. https://github.com/rfjakob/gocryptfs/issues/754 2023-06-09T13:07:45+00:00 Jakob Unterwurzacher 2023-06-09T12:35:04+00:00 urn:sha1:751acc4698aa299624a593745d0daf82f5a4fe10 Add the -sharedstorage flag to the mounts and make it more severe by adjusting the I/O and file sizes to arbitrary unaligned values. It passes *most of the time*. If it fails, it's like this, and the reason is that there is no fcntl locks in the READ path yet. gocryptfs/tests/cluster$ go test -run TestClusterConcurrentRW -v === RUN TestClusterConcurrentRW doRead 2895433: corrupt block #0: cipher: message authentication failed doRead 2895433: corrupt block #0: cipher: message authentication failed doRead 2895433: corrupt block #0: cipher: message authentication failed cluster_test.go:98: readThread iteration 9165: ReadAt failed: read /var/tmp/gocryptfs-test-parent-1026/3021427391/TestClusterConcurrentRW.366469887.mnt1/foo: input/output error --- FAIL: TestClusterConcurrentRW (0.40s) FAIL exit status 1 FAIL github.com/rfjakob/gocryptfs/v2/tests/cluster 0.406s 2023-06-09T13:07:45+00:00 Jakob Unterwurzacher 2023-06-09T12:34:20+00:00 urn:sha1:d8f4bdb72a1bcef509fd3e4258c96f8f67db8203 As we must write complete ciphertext blocks (except at EOF), non-overlapping plaintext writes can overlap in the ciphertext. And because overlapping writes can turn the data into data soup (see TestPoCTornWrite) we serialize them using fcntl locking. 2023-06-09T12:33:07+00:00 Jakob Unterwurzacher 2023-06-09T12:33:07+00:00 urn:sha1:5ae35e904ab7b536a8c8c8a05cd8c69953b3b093 2023-06-09T05:50:11+00:00 Jakob Unterwurzacher 2023-06-09T05:50:11+00:00 urn:sha1:1b4dc795bd0060bd64992f1355cbf197e0a20172 2023-06-09T05:30:04+00:00 Jakob Unterwurzacher 2023-06-08T19:35:45+00:00 urn:sha1:5d78814da3786ed0786234ec5249723018274355 Turns out we can get the same error with a simpler flow. 2023-06-09T05:29:54+00:00 Jakob Unterwurzacher 2023-06-08T13:50:05+00:00 urn:sha1:1418565a6b28a91f2f15d5b957d7fd31392a47a1 Scary. But explains why TestConcurrentCreate fails. gocryptfs/tests/cluster$ go test -run TestPoCTornWrite --- FAIL: TestPoCTornWrite (0.00s) poc_test.go:210: iteration 214: inconsistent block: d6d6d6d6d6d6d6d6d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1d1 FAIL 2023-06-09T05:29:49+00:00 Jakob Unterwurzacher 2023-06-08T13:04:22+00:00 urn:sha1:2b416942b0366c41672bf6bab69b2f1a1ceb5f5d