Received-SPF: pass (google.com: domain of linux-ext4+bounces-833-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Wed, 17 Jan 2024 00:28:21 -0500
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Brian J. Murrell" <brian@interlinx.bc.ca>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Protecting lost+found from rmdir by directory owner?
Message-ID: <20240117052821.GK911245@mit.edu>
References: <42bc44533e997531baa79c73867a942504122886.camel@interlinx.bc.ca>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42bc44533e997531baa79c73867a942504122886.camel@interlinx.bc.ca>

On Tue, Jan 16, 2024 at 08:26:14AM -0500, Brian J. Murrell wrote:
> Let's say I create a new ext4 filesystem for exclusive use by alice and
> when I mount it, say, on /mnt/alice I set the permissions so that alice
> can work in that directory:
> 
> # mkfs.ext4 /dev/foo
> # mount /dev/foo /mnt/alice
> # chown alice:alice /mnt/alice
> # chmod 775 /mnt/alice
> 
> But now /mnt/alice/lost+found is at the mercy of alice since she has
> write permission for /mnt/alice.
> 
> [How] can I protect /mnt/alice/lost+found from removal by alice?

You can't.  Note that if /lost+found is missing, e2fsck will try to
recreate it if it finds orphaned inodes (e.g., inodes that aren't
connected to the the directory tree).  The reason why mke2fs
pre-creates the lost+found directory is adds a bit more reliability,
in the case where there are no free inodes or free blocks to create
the lost+found directory.  There's also a very tiny risk where if the
file system is horrendously corrupted, asking e2fsck to recreate
lost+found is one more thing that could potentially go wrong.

On the other hand, if the file system is created exclusively for
alice, and she remotes lost+found, in the rare case where something
goes horrendously wrong, she's the only person who would suffer.
Ultimately, just like we can't protect users from yanking out USB
drives before unounting them and waiting for the writes to complete,
sometimes asking users to take personal responsibility is the best
policy.

And for most users, the case that they might accidentally type a
command like "rm * -i" or someone who believes advice from irc that
"rm -rf ~/" is a way to "Read Mail Really Fast", is probably much more
likely than the file system gets so badly corrupted that /lost+found
is going to make that much of a difference.  And that's what backups
are for in any case, right?  :-)

Cheers,

					- Ted