linux-kernel - "Resetting" an overlay fs entry; clearing the upper layer and revealing the lower layer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <PH7PR14MB55699F84995FB1FBBEA5663BF53BA@PH7PR14MB5569.namprd14.prod.outlook.com>
Date:   Mon, 17 Jul 2023 22:30:18 +0000
From:   John Ericson <john.ericson@...idian.systems>
To:     LKML <linux-kernel@...r.kernel.org>
CC:     Nathan Homesley <nathan.homesley@...idian.systems>,
        Ryan Mulligan <ryan@...l.it>
Subject: "Resetting" an overlay fs entry; clearing the upper layer and
 revealing the lower layer 

We would like to be able to "reset" an overlay-fs directory entry, i.e. remove whatever might exist for this entry in the upper layer and revert back to whatever is in lower layer. This operation would be akin to a regular removal, except without creating whiteouts to cover up anything in the lower layer.

As far as our team could discern, the kernel currently does not support this operation. Thus, we are considering what would be necessary to implement this ourselves. Our initial exploration led us to `ovl_do_remove` within `fs/overlayfs/dir.c` and in particular this conditional:

    if (!lower_positive)
        err = ovl_remove_upper(dentry, is_dir, &list);
    else
        err = ovl_remove_and_whiteout(dentry, &list);

That seemed like a good place to begin --- if one were to force the first case no new whiteouts would be created, correct?

Assuming that is indeed the right place to start, I have two follow-up questions.

1. Since the desired end result of the operation is strictly closer to the lower layer, should we possibly eliminate some of the other operations in a fresh copy of this function? For instance, might `ovl_copy_up` be unnecessary because if the upper layer already doesn't "contribute" to this dir entry, no action would need to be taken? Additionally, what is the significance of `nlink`? We have not found much documentation for it; from what we understand, it's an `xattr` used so some information for the overlay-fs is persisted on disk.

2. What is the recommended approach to expose this functionality? We assume it would be through a new `ioctl`, but with no existing overlay-fs-specific `ioctl` as a reference, we are unsure if that would be the correct choice. We presume there are best practices on this matter that we are not currently aware of.

Our intention is to upstream this patch if we write it. It would be therefore beneficial to discuss any objections or concerns beforehand. For instance, one possible issue could be overlay-fs usage which presumes that covered up lower layer data is private and inaccessible. To make it possible to preserve that invariant, permissions for this operation would have to be distinct from write permissions. This concern can thus be addressed, but it would increase the scope of the patch.

Thanks,

John