On Tue, May 31, 2016 at 11:44 AM, Ashish Sangwan <ashishsangwan2@xxxxxxxxx> wrote: > On Tue, May 31, 2016 at 2:40 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> On Tue, May 31, 2016 at 11:04 AM, Ashish Sangwan >> <ashishsangwan2@xxxxxxxxx> 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. You don't need that. The only thing you need is that access is based on user/group(s). If that's not the case (e.g. some other attribute of the process doing the access is used) then this will indeed not work. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
