Permission check for FIFO open in FUSE(filesystem)

I am trying to open a FIFO for which permissions doesn't exists for the uid trying to open a file in FUSE(filesystem). I know that for FIFO open call will not come to FUSE and directly handled by kernel, but FUSE open call does the permission checks from fuse_context. How, is it possible, that permission can be denied because the call is not coming in FUSE. I have a stack trace for open system call for BLOCKING open for FIFO. Here after dentry_open we got to fifo_open in kernel, without going to fuse.

pipe_wait+0x61/0xa0
wait_for_partner+0x30/0x60
fifo_open+0x195/0x2d0
do_dentry_open+0x233/0x2e0
vfs_open+0x49/0x50
do_last+0x562/0x1370
path_openat+0xbb/0x670
do_filp_open+0x3a/0x90
do_sys_open+0x129/0x2a0
But for other file type, we get open call inside FUSE.

fuse_open+0x10/0x20
do_dentry_open+0x233/0x2e0
vfs_open+0x49/0x50
do_last+0x562/0x1370
path_openat+0xbb/0x670
do_filp_open+0x3a/0x90
do_sys_open+0x129/0x2a0
Is it possible, that the permission checks can be done for FIFO files managed by FUSE while opening. If not, how is it possible to deny permissions for FIFO opened by users not having FIFO write permissions in FUSE. If this a bug, is it in libfuse or kernel.

[Nikratio]

I'm afraid I can't completely follow your question. Are you asking why you are getting a "Permission denied" error when opening a FIFO, despite your open() handler not being called? If so, you may want to look at the access handler and the default_permissions mount option. If not, could you rephrase your question?

Please also note that the stack traces that you quoted are from the fuse kernel module, while this project is about the libfuse userspace library. So you may also want to ask on the linux kernel mailing lists if your question is kernel related.

[Nikratio]

I'm closing this bug report for now. Please note that this isn't meant to imply that you haven't found a bug - you most likely have and I'm grateful that you took the time to report it. However, without additional information it is unlikely that anyone is going to be able to do anything but this, and I prefer to use the issue tracker as a tool to manage ongoing work (as opposed to a database of known/potential issues).

Please feel free to re-open this if you can provide the requested information!

[davies]

I hits this problem also, the FUSE kernel module does not perform permission checking correctly when open a FIFO (it should deny a open with write for a FIFO with mode 0444), we can reproduce it by run pjdfstest on any FUSE filesystems.

Inside a path on FUSE filesystem,

$ sudo prove -r path-to-pjdfstest/tests/open/06.t -v 

[ben-z]

I came across the same when trying to pass all of the pjdfstests. Here's a simple way to reproduce:

mkfifo testfifo
chmod u-r testfifo
cat testfifo

The expected behaviour is getting "Permission denied". The actual behaviour is there's no error message and the FIFO works as if no permission checking is done.

with FUSE (high-level API), only a getattr call is made.

I see the correct behaviour (permission denied) on CephFS, which uses FUSE. I wonder how they implemented this permission-checking functionality.

EDIT: Just realized that FUSE has a default_permissions option. When this option is enabled, most of the pjdfstests pass automatically (because most of them are for permission checking).