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
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.