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
