Home / ubuntu / Questions / 1113282
Accepted
PerlDuck
Asked: 2019-01-28 05:58:58 +0800 CST

Is `chown user:user lost+found` harmful?

  • 772

Recently I created an encrypted filesystem (crypto_LUKS) that serves as $HOME for just one particular user (i.e. I mount it as /home/pduck). I also added an appropriate entry in /etc/security/pam_mount.conf.xml so that the partition gets automatically decrypted and mounted when the user logs in (and unmounted when he logs off). Works great.

Because the $HOME is a filesystem on its own, the user has a lost+found directory owned by root:root in it. I know that deleting the directory is a bad idea but many commands (e.g. find) complain about having no access. That annoys me.

Out of curiosity I removed the directory and recreated it with mklost+found (without sudo). Now the directory is owned by pduck:pduck. Is that ok or is it crucial that the directory is owned by root:root?

permissions partitioning mount chown

3 Answers

  1. Best Answer

    Good advice comes with a rationale so that you can tell when it becomes bad advice.

    The purpose of lost+found being owned by root is so that no matter whose file it was that was lost it's not suddenly exposed to everybody. However, in this case, there shouldn't be a single file in the entire filesystem* not owned by pduck; therefore there is no downside to lost+found not being owned by pduck.

    *barring exotic situations like pduck suing to root and running an X application. But if pduck can use sudo or su than we're talking about nothing because pduck can break system security outright.

    • 12

  2. lost+found is a system directory, and I avoid tampering with the ownership and permissions of system directories and files.

    There are other directories (and files), that make find complain, unless I elevate the permissions of the command line, so I suggest that you use

    sudo find ...

    and leave lost+found as it {is/should be}.

    • 6

  3. There is nothing really magical about the lost+found directory. It's just a plain directory just like any other and is only used to hold lost files/directories found during a fsck after a system crash or filesystem corruption.

    It's created during mkfs when the file system is created and is normally empty. The only reason for the default permissions is to avoid sensitive files from becoming visible to regular users if they are found and recovered during an fsck. In the modern era it's rare to see files get lost and put into that folder.

    If it's removed, I believe fsck will recreate it as needed if there happens to be any files that need to be put into there. Since this is a file system for one user and his data alone with no need to keep the data hidden from prying eyes, I see no reason that the permissions couldn't be changed to, say, 755 to prevent find from complaining or changing it's ownership. It's possible that fsck might reset it's permissions during a recovery process, but that's a rare event on a modern file system unless there's serious hardware failure.

    As for just removing it, I believe all of the paranoia around that is based on the fact it's best to have fsck do at little as possible to recover data, but I don't think it really matters much in practice.

    • 4