On Wed, Mar 13, 2019 at 1:31 PM Richard Weinberger <richard@xxxxxx> wrote: > > Hi! > > overlayfs and fscrypt are not friends. > Currently it is not possible to use a fscrypt encrypted directory as upper > directory with overlayfs. > The reason for that is, fscrypt implements ->d_revalidate(). > > From fscrypt's point of view having ->d_revalidate() makes sense because it > wants to hide/show encrypted filenames if someone loads or unlinks a key. > > On the other hand, overlayfs makes sure that the upper directory cannot > change beneath it. Therefore it checks whether the upper directory is a remote > filesystem by checking for ->d_revalidate() and refuses to mount if so. > > In my little embedded Linux world it is common to use both UBIFS and > overlayfs. Now with UBIFS being encrypted using fscrypt, overlayfs is a > problem. > My current hack is not using fscrypt_d_ops in UBIFS. This works because on a > typical embedded target you setup your crypto keys exactly once, right before > you mount overlayfs in an initramfs. > > But I'm sure this problem will hit sooner or later users of ext4 and f2fs too. > Therefore I'd like to discuss possible solutions. > > So far I see two options: > > 1. Get rid of ->d_revalidate() in fscrypt. > Maybe we find a way to return a dentry via ->lookup() which is not cached at > all and therefore no ->d_revalidate() is needed. If unreadable and encrypted > filename lookups are slow, so what? > AFAIU this approach is impossible in the current dcache design since it is not > allowed to have more than one dentry to the same file. I don't get it. Does fscrypt try to check permissions via ->d_revalidate? Why is it not doing that via ->permission()? > > 2. Teach overlayfs to deal with a upper that has ->d_revalidate(). > Given the complexity of overlayfs I'm not sure how feasible this is. > But I'm no overlayfs expert, maybe I miss something. I don't think it would be too complex. But first I'd like to understand exactly why fscrypt is (ab) using d_revalidate(). Thanks, Miklos
