When a cifs mount point marked in fanotify with OPEN_PERM mark, access to some files can be denied despite an access is allowed by fanotify. An antiviral software monitors files on a cifs share. An editor tries to work with a document on the share. Beside it creates a lock file and a temporary file for the document. When the editor tries to store a data to the file, it fails with an error "cannot create reserved copy of the document". I simulate the antiviral software by a fanotify.c (it is a reworked sample from fanotify(7)) and the editor by a script test.sh (both are attached). An strace log of the test.sh (attached) shows EPERM during an attempt to open the document on read/write before making copy of the tempfile into the document. 10920 openat(AT_FDCWD, "/mnt/boxes/test2.docx", O_RDWR|O_CREAT, 0666) = -1 EPERM (Operation not permitted) When I run the test.sh without fanotify, everything works correctly. Such behaviour can be also simulated with an almost exact sample fanotify_example.c from fanotify(7) with an added delay before allowing, but it reproduced not always. The bug can be reproduced on old kernels too. Reproducible: Always Steps to Reproduce: 1. compile attached fanotify.c 2. mount CIFS share to /mnt/boxes 3. run ./fanotify /mnt/boxes 4. run attached ./test.sh Actual Results: the test fails with an error Expected Results: the test succeeds [root@fedora ~]# uname -a Linux fedora 6.2.9-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Mar 30 22:32:58 UTC 2023 x86_64 GNU/Linux
Created attachment 1967678 [details] a simulator of the antiviral software
Created attachment 1967679 [details] a simulate script of the editor
Created attachment 1967688 [details] an output of the test script
Created attachment 1967689 [details] dmesg output with the reproduction
Created attachment 1967690 [details] strace output of the script
Created attachment 1967691 [details] dmesg output of the correct work
Created attachment 1967692 [details] an output of the correct work of the script