From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB8A7C43381 for ; Wed, 13 Mar 2019 12:31:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A0D80214AE for ; Wed, 13 Mar 2019 12:31:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726431AbfCMMbW (ORCPT ); Wed, 13 Mar 2019 08:31:22 -0400 Received: from lithops.sigma-star.at ([195.201.40.130]:41724 "EHLO lithops.sigma-star.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725893AbfCMMbW (ORCPT ); Wed, 13 Mar 2019 08:31:22 -0400 Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 71025609187E; Wed, 13 Mar 2019 13:31:19 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 8NsQbv6QpKFp; Wed, 13 Mar 2019 13:31:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id DD2A4609186C; Wed, 13 Mar 2019 13:31:18 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IU7AkRYfsYUw; Wed, 13 Mar 2019 13:31:18 +0100 (CET) Received: from blindfold.localnet (unknown [82.150.214.1]) by lithops.sigma-star.at (Postfix) with ESMTPSA id 86017608A389; Wed, 13 Mar 2019 13:31:18 +0100 (CET) From: Richard Weinberger To: linux-fsdevel@vger.kernel.org Cc: linux-fscrypt@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: overlayfs vs. fscrypt Date: Wed, 13 Mar 2019 13:31:17 +0100 Message-ID: <4603533.ZIfxmiEf7K@blindfold> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. What else could we do? Thanks, //richard