This old text was never updated to mention ext4 in addition to ext2 and
ext3. Do so now. Also don't bother to mention old unmerged patches.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
- "can only be open" => "can only be opened"
- "is not candidate" => "is not a candidate"
- "written ... on the disk" => "written ... to the disk"
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
When the casefold attribute ('F') was added to the chattr man page, it
was forgotten to add it to the mode string. Add it.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Adjust the documentation for the encryption attribute ('E') to clarify
that encryption isn't experimental anymore and isn't restricted to
regular files, and that the encryption is done by the filesystem.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The AX_CHECK_MOUNT_OPT macro fails if /usr/include/sys/mount.h.
Unfortunately, the GNU HURD doesn't have this header file. Drop the
requirement, since if it doesn't exist, the macro will assume that
given mount options don't exist, which for e2fsprogs is used to test
to for the existence of the mount options nosuid and nodev. This is
only used for fuse2fs, and HURD doesn't support fuse2fs anyway.
Addresses-Debian-Bug: #944649
Reported-by: Svante Signell <svante.signell@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If there is a trickster which tries to use device names as the mount
device for pseudo-file systems, the resulting /proc/mounts can confuse
ext2fs_check_mount_point(). (So far as I can tell, there's no good
reason to do this, but sysadmins do the darnest things.)
An example of this might be the following /proc/mounts excerpt:
/dev/sdb /mnt2 tmpfs rw,relatime 0 0
/dev/sdb /mnt ext4 rw,relatime 0 0
This is created via "mount -t tmpfs /dev/sdb /mnt2" followed via
"mount -t ext4 /dev/sdb /mnt". (Normally, a sane mount of tmpfs would
use something like "mount -t tmpfs tmpfs /mnt2".)
Fix this by double checking the st_rdev of the claimed mountpoint and
match it with the dev_t of the device. (Note that the GNU HURD
doesn't support st_rdev, so we can't solve this problem for the HURD.)
Reported-by: GuiYao <guiyao@huawei.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Currently, the estimate of minimum filesystem size is using free blocks
counter in the superblock. The counter generally doesn't get updated
while the filesystem is mounted and thus the estimate is very unreliable
for a mounted filesystem. For some usecases such as automated
partitioning proposal to the user it is desirable that the estimate of
minimum filesystem size is reasonably accurate even for a mounted
filesystem. So use group descriptor counters of free blocks for the
estimate of minimum filesystem size. These get updated together with
block being allocated and so the resulting estimate is more accurate.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
gregor herrmann reports that the weekly e2scrub cronjob emits these
errors:
/sbin/e2scrub_all: line 173: /proc/8234/fd/pipe:[90083173]: No such file or directory
The root cause of this is that the ls_targets stdout is piped to stdin
to the entire ls_targets loop body to prevent the loop body from reading
the loop iteration items. Remove all the broken hackery by reading the
target list into a bash array and iterating the bash array.
Addresses-Debian-Bug: #944033
Reported-by: gregor herrmann <gregoa@debian.org>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Dave Chinner complains that the automated on-boot e2scrub reaping takes
a long time (because the lvs command can take a while to run) even
though the automated e2scrub is disabled via e2scrub.conf on his
systems.
We still need the reaping service to kill off stale e2scrub snapshots
after a crash, but it's unnecessary to annoy everyone with slow bootup.
Because we can look for the e2scrub snapshots in /dev/mapper, let's
skip reaping if periodic e2scrub is disabled unless we find evidence of
e2scrub snapshots in /dev.
Reported-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This avoids a potential UBsan failure when we multiply an insanely
high block number with the block size and we get a multiplication
overflow.
Google-Bug-Id: 128130353
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Use ext2fs_free_{block,inode}_bitmaps() instead of ext2fs_free_mem()
to avoid some memory leaks if there is an error while calling
read_bitmaps().
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If count * block_size exceeds 2GB, we will overflow a 32-bit signed
integer value. This shouldn't happen in practice except for
fuzz-corrupted file systems, but let's fix the code so it's correct.
Bug: https://github.com/tytso/e2fsprogs/issues/24
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The testing links are not stable and are not guaranteed to exist.
Test: After re-generating the generated files, the link works now.
Change-Id: I36e73ef74571b3246f470280a75ae1098245eff5
From AOSP commit: 5971f6a5113b12b33d9454229bf27621853e1da7
Test: see I3781b6d1e55923e9410644e8a7ba834b4d13b733
Change-Id: Ie071b30937dcf73f34df5dc3aa08d23ae30d9c63
From AOSP commit: d2a16e1616b807a6143b9c6232a1c54f90dc06f6
Try to make it clearer that enabling 'encrypt' just enables *support*
for encryption; it doesn't actually encrypt anything by itself.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Try to make it clearer that enabling 'encrypt' just enables *support*
for encryption; it doesn't actually encrypt anything by itself.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The features are listed in alphabetic order, so put the casefold feature
in the right place.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Some versions of cron leave fd 3 open for some unknown reason. So
when e2scrub_all is run by cron (on non-systemd systems) this results
in an annoying message from the Cron Daemon because lvm will print
warning messages about "leaked file descriptors. So force close fd 3
at the beginning of e2scrub and e2scrub_all.
Addresses-Debian-Bug: #940240
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
A maliciously corrupted file systems can trigger buffer overruns in
the quota code used by e2fsck. To fix this, add sanity checks to the
quota header fields as well as to block number references in the quota
tree.
Addresses: CVE-2019-5094
Addresses: TALOS-2019-0887
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The backup superblock may have a last mounted time of zero, if it has
never been updated since the file system was created. In that case,
the low dtime check may get disabled when using the backup superblock,
even though subsequent e2fsck runs will end up using the low dtime
check. This can cause a failure of ext4/007, since since when e2fsck
is run a second time after the file system is mounted, the low dtime
check will trigger the e2fsck complaint:
Inode NNNN was part of the orphaned inode list. IGNORED.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This is done correctly by the fileio routines; and it forces the quota
inode's file size to be unnecessarily rounded up to the block size.
Also remove the unnecessary double colon in the quota's error messages.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If the volume group's free space is exactly the same as snapshot size,
e2scrub_all will skip those logical volumes in those volume groups.
Fix this by changing the test from '>' to '>='.
Fixes: c120312253 ("e2scrub_all: make sure there's enough free space...")
Addresses-Debian-Bug: #935009
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
LTO breaks reproducible builds, and there is some question as to how
reliable LTO's code generator is --- there are some scary stories that
it doesn't work well, and the GCC maintainers aren't super-interested
in fixing the bugs:
https://lists.debian.org/debian-devel/2019/07/msg00610.html
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This was done automatically by debhelper, but it got dropped when
override_dh_auto_test was added by commit 7f4c3bb120 ("debian: run
"make check" with V=1 to keep blhc happy").
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Also fix logsave so it is Architecure: any. It was previously
"linux-any kfreebsd-any" due to a cut-and-paste error.
Addresses-Debian-Bug: #932876
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
