Bug 962008 - forbid the creation/usage of a mount point over an ext2/3/4 partition's lost+found directory in anaconda custom partitioning
forbid the creation/usage of a mount point over an ext2/3/4 partition's lost+...
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-05-10 18:56 EDT by Reartes Guillermo
Modified: 2013-05-14 20:29 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-05-14 20:29:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Reartes Guillermo 2013-05-10 18:56:41 EDT
Description of problem:

Currently, anaconda permits a /lost+fount mount point. I believe anaconda should not accept any storage configuration in which any being created mount point would mount itself over any 'lost+found' directory. I think 'lost+found' should be a reserved word or something like that.

A user might still setup such configuration manually post-install, but that is another story and has nothing to do with anaconda.


No /lost+found, /boot/lost+found, etc. as mount points.

Version-Release number of selected component (if applicable):
F19b TC4 (19.25-1)

How reproducible:

Steps to Reproduce:

0. Reach the Main Hub, set English because Portuguese is still selected by default. The correct one would be Spanish.
1. I selected 'Minimal' Base Environment
2. Enter Storage: Installation Destination and do custom partitioning (1 disk guest) using 'standard partition' partition scheme.
3. Add a swap (768mb)
4. Add a /boot (512mb)
5. Add a /lost+found (120mb)
   YES! it is not a joke.
6. Add a / with the rest of the disk.
7. Return to the Main Hub and perform the installation.

Actual results:
A fake /lost+found, with different permissions.
There might be real files under the real one.

Expected results:
Anaconda refusal to create such storage configuration.

Additional info:

* LOST+FOUND on a F17 system:

# ls -ld /lost+found/
drwx------. 2 root root 16384 May 22  2012 /lost+found/
# ls -ldZ /lost+found/
drwx------. root root system_u:object_r:lost_found_t:s0 /lost+found/

*A 'FAKE' LOST+FOUND on a F19b TC4 system:

# ls -ld /lost+found/
drwxr-xr-x. 3 root root 1024 May 10 19:31 /lost+found/
# ls -ldZ /lost+found/
drwxr-xr-x. root root system_u:object_r:lost_found_t:s0 /lost+found/

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       8.2G  638M  7.1G   9% /
devtmpfs        492M     0  492M   0% /dev
tmpfs           498M     0  498M   0% /dev/shm
tmpfs           498M  368K  498M   1% /run
tmpfs           498M     0  498M   0% /sys/fs/cgroup
tmpfs           498M  4.0K  498M   1% /tmp
/dev/sda1       488M   61M  403M  14% /boot
/dev/sda5       112M  1.6M  104M   2% /lost+found

* From FSH v2.3: Section 1.10. /lost+found

> [...] Each partition has its own lost+found directory. 
> If you find files in there, try to move them back to their original location. [...]

So there could be files that only root should see on a lost+found entry after a crash, but if there is another filesystem mounted over a lost+found, those files would be not visible. On the whole section, it is described as 
a directory that is used/created by fsck, it is never ever called a mount point.
Comment 1 Brian Lane 2013-05-14 20:29:24 EDT
There are too many possible permutations of this. It doesn't cause a traceback, so I'd call it user error.

Note You need to log in before you can comment on or make changes to this bug.