Join GitHub today
Without `default_permissions`, cached permissions are only checked on first access #15
When the inodes are cached by fuse (non-zero attr_timeout), and the standard_permissions are used, the following sequence :
The "chmod 000" should have led to an EACCES error for the subsequent commands.
This was reported in 2009 (http://article.gmane.org/gmane.comp.file-systems.fuse.devel/8099), and according to http://article.gmane.org/gmane.comp.file-systems.fuse.devel/15300 some work is still needed on it.
This means that for being Posix compliant, fuse file systems cannot either use the cache or have the permissions checked by the kernel.
Would this fix http://sourceforge.net/p/fuse/mailman/message/34801725/ too. Because the attr-timeout has nothing to do with the issue reported (the entry timeout has to be > 0). By standard permissions do you mean default permissions turned off ?
Satya G S wrote:
I do not fully understand what you mean (what has
When the kernel needs to dig into a directory on
Your results show this is not yet the case.
attr-timeout (I mean the last argument of fuse_reply_attr())
On Linux, ntfs-3g usually uses default_permissions (yes,
[linux@dimension linux]$ ./try.sh
On OpenIndiana (same fuse library), ntfs-3g can use
Note : the proper behavior of permissions is checked by
Hum, yes you are right. The issue occurs with default_permissions not enabled, and with permissions checked by the user-level file system. I have recompiled ntfs-3g with a timeout of 10 seconds (both attr and entry timeouts), and executed as root the following script :
Note that this script never changes the permissions on the directory "trydir". The expected output is :
The error on last line is caused by the user ("linux") not being allowed to list "trydir".
And trydir could be listed...
Also note the user-level file system has no opportunity to invalidate an entry. There is no action triggering a change.
I have replayed the shell script shown in the original post, and I can confirm the bug is still present, but only when the option default_permissions is NOT used.
for Nikolaus : maybe you can change the title to "The directory entries cached by fuse are not checked against the current user permissions"
Thank you for confirming the behaviour. This issue hurts every filesystem that has support for ACLs. Setting the entry timeout to zero will result in too many up calls to filesystem.
Isn't this a place to track library issues. This looks like a kernel bug to me.
I agree, not using the cache is inefficient because it implies making more calls to the user-level file system. The same goes for not using default_permissions.
So I am not insisting on this bug to be fixed, I would rather call for default_permissions to support the same permission checks as ext2/3/4.
I also call for the cache to support hard links, and this is specific to the high-level library interface, there is no problem with the low-level one.
These are the two reasons why ntfs-3g gave up using the cache on Linux (except when using the low-level interface and not using the Posix ACLs).
Yes, when writing the kernel code there was probably an implicit assumption that allow_other" would not be used (or maybe it didn't exist at that point). With allow_other, this becomes a security bug.
You are right. I asked Jean-Pierre to file it here so that there's at least a permanent record (give that this was first reported on the kernel ml in 2006).
Nikolaus Rath wrote:
I think this is not correct : in my first example and
So my feeling is that there is no check at all.
My text change proposal :
changed the title
Cached directory entry permissions are only checked for first accessing user
Mar 1, 2016
referenced this issue
Mar 9, 2016
gocryptfs developer here. I don't understand why this is declared a kernel bug (but on the other hand I can't click the gmane links because it has been shut down).
Isn't just that the user-space filesystem fails to check the permissions on READDIR? (This is the opportunity to check the permissions, there is no need for an extra LOOKUP)
@rfjakob : see my example try2.sh, there is no readdir at all (no wildcards). Creating "trydir/file" is just a create() in write-only directory "trydir" (which is allowed, though directory is unreadable). Later on, for executing "trydir/file", there is no lookup from "trydir", and the user space has no chance of checking whether "trydir" is readable. When "file" is opened, the user space does not know from which directory it is opened (a file may be referenced in several directories with different permissions).
Ok, I think I get it. When there are multiple hard links of one file in different directories, user-space cannot decide which directory to check. It's quite a corner-case, but still.
Note that the kernel knows about the user and this info is also passed to user-space in every request:
I'm trying to compile under Windows using сygwin, but eventually do make-j8 command error occurs
> ../include/fuse_kernel.h:759:41: error: expected expression before 'uint32_t'
Please help deal with this problem, which is already just trying to build library, but this error does not allow it to make