Page MenuHomeFreeBSD

makefs(8) improper error handling (or lack of thereof)
ClosedPublic

Authored by sobomax on Dec 17 2018, 4:42 PM.

Details

Summary

There is some dubious error handling within the makefs(8) utility. If some file to be packaged cannot be read (most likely due to EPERM), it would issue a warning and proceed creating slighly inconsistent FS image. The correct behavior I think is to abort and return an error back to caller.

$ ./makefs_bug.sh
+ mktemp -d test.XXXXXXXXX
+ TDIR=test.tdVMsj79c
+ mkdir test.tdVMsj79c/somedir
+ truncate -s 1024k test.tdVMsj79c/somedir/somefile
+ chmod 000 test.tdVMsj79c/somedir/somefile
+ makefs test.tdVMsj79c.ufs test.tdVMsj79c
Calculated size of `test.tdVMsj79c.ufs': 1212416 bytes, 4 inodes
Extent size set to 32768
test.tdVMsj79c.ufs: 1.2MB (2368 sectors) block size 32768, fragment size 4096
        using 1 cylinder groups of 1.16MB, 37 blks, 256 inodes.
super-block backups (for fsck -b #) at:
 64,
Populating `test.tdVMsj79c.ufs'
makefs: Can't open `test.tdVMsj79c/./somedir/somefile' for reading: Permission denied
Image `test.tdVMsj79c.ufs' complete
+ rm -rf test.tdVMsj79c
+ sudo mdconfig -a -f test.tdVMsj79c.ufs
+ mdu=md0
+ sudo mount -o ro /dev/md0 /mnt
+ ls /mnt/somedir/somefile
ls: /mnt/somedir/somefile: Bad file descriptor
Test Plan
#!/bin/sh

set -e
set -x

TDIR=`mktemp -d test.XXXXXXXXX`
mkdir ${TDIR}/somedir
truncate -s 1024k ${TDIR}/somedir/somefile
chmod 000 ${TDIR}/somedir/somefile
makefs ${TDIR}.ufs ${TDIR}
rm -rf ${TDIR}
mdu=`sudo mdconfig -a -f ${TDIR}.ufs`
sudo mount -o ro /dev/${mdu} /mnt
ls /mnt/somedir/somefile
sudo umount /mnt
sudo mdconfig -d -u ${mdu}
rm ${TDIR}.ufs

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

sobomax created this revision.Dec 17 2018, 4:42 PM
sobomax edited the test plan for this revision. (Show Details)
sobomax edited the summary of this revision. (Show Details)

I think this is reasonable - certainly an error is better than creating a corrupt filesystem.

Is it possible to mimic what tar does though -- skip the unreadable file, carry on with other files, and return error code at the end?

We should also coordinate with NetBSD.

This revision was not accepted when it landed; it landed in state Needs Review.Feb 25 2019, 11:45 PM
This revision was automatically updated to reflect the committed changes.