From: Nikolaus Rath <Nikolaus@rath.org>
To: Ashish Sangwan <ashishsangwan2@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
fuse-devel <fuse-devel@lists.sourceforge.net>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] fuse: callback for invalidating cached children dentries for a directory
Date: Tue, 31 May 2016 09:01:35 -0700 [thread overview]
Message-ID: <871t4i9py8.fsf@thinkpad.rath.org> (raw)
In-Reply-To: <CAOiN93kO07mM0C=VX7NVVzcdeVuRuWBGLV112xWDvXFzu-Lsag@mail.gmail.com> (Ashish Sangwan's message of "Tue, 31 May 2016 15:14:26 +0530")
On May 31 2016, Ashish Sangwan <ashishsangwan2@gmail.com> wrote:
> On Tue, May 31, 2016 at 2:40 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> On Tue, May 31, 2016 at 11:04 AM, Ashish Sangwan
>> <ashishsangwan2@gmail.com> wrote:
>>> This patch solves a long standing bug.
>>> "([bug #15](https://github.com/libfuse/libfuse/issues/15)): if the
>>> `default_permissions` mount option is not used, the results of the
>>> first permission check performed by the file system for a directory
>>> entry will be re-used for subsequent accesses as long as the inode of
>>> the accessed entry is present in the kernel cache - even if the
>>> permissions have since changed, and even if the subsequent access is
>>> made by a different user.
>>> This bug needs to be fixed in the Linux kernel and has been known
>>> since 2006 but unfortunately no fix has been applied yet. If you
>>> depend on correct permission handling for FUSE file systems, the only
>>> workaround is to use `default_permissions` (which does not currently
>>> support ACLs), or to completely disable caching of directory entry
>>> attributes. Alternatively, the severity of the bug can be somewhat
>>> reduced by not using the `allow_other` mount option."
>>>
>>> This patch introduce a callback which the user space implementation can use
>>> to invalidate the cached entries of a parent directory, for example when
>>> the execute permissions are revoked and force real lookup.
>>
>> This doesn't solve the real problem.
>
> Agree.
>>
>> As I just mentioned, the bigger problem is that when doing cached
>> lookups we ignore the credentials of the current process. Without
>> that (and without default_permission) we just can't make a good
>> decision whether to allow the cached lookup or not.
> IMHO even that won't be enough. For the file system, like ours, which
> has its own
> security policies and does not use default_permission, there is no
> straight forward
> match of the user credentials to the standard mode bits/uid/gids etc.
> Checking for these at the time of cached lookup will break the semantics of not
> using default_permission.
> I think the best bet for now is to set entry timeout to 0 seconds and
> let every lookup
> reach the library.
I think that's the only solution for such access policies in general
(not just for now). Any attempt to tell the kernel when to invalidate
will be prone to race conditions. If the kernel does not understand your
permission model, you cannot use caching. Period.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
prev parent reply other threads:[~2016-05-31 16:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 9:04 [PATCH] fuse: callback for invalidating cached children dentries for a directory Ashish Sangwan
2016-05-31 9:10 ` Miklos Szeredi
2016-05-31 9:44 ` Ashish Sangwan
2016-05-31 9:58 ` Miklos Szeredi
2016-05-31 16:01 ` Nikolaus Rath [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871t4i9py8.fsf@thinkpad.rath.org \
--to=nikolaus@rath.org \
--cc=ashishsangwan2@gmail.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.