On May 31 2016, 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. > 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.« -- 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
