From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f65.google.com ([209.85.218.65]:34240 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756398AbcEaJKn (ORCPT ); Tue, 31 May 2016 05:10:43 -0400 Received: by mail-oi0-f65.google.com with SMTP id r64so29508125oie.1 for ; Tue, 31 May 2016 02:10:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1464685454-19650-1-git-send-email-ashishsangwan2@gmail.com> References: <1464685454-19650-1-git-send-email-ashishsangwan2@gmail.com> Date: Tue, 31 May 2016 11:10:42 +0200 Message-ID: Subject: Re: [PATCH] fuse: callback for invalidating cached children dentries for a directory From: Miklos Szeredi To: Ashish Sangwan Cc: Nikolaus Rath , fuse-devel , linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, May 31, 2016 at 11:04 AM, Ashish Sangwan 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. 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. Thanks, Miklos