standards/176412: newfs writes by default, compare to bsdlabel/disklabel.
Giorgos Keramidas
keramida at FreeBSD.org
Mon Mar 4 14:50:01 UTC 2013
The following reply was made to PR standards/176412; it has been noted by GNATS.
From: Giorgos Keramidas <keramida at FreeBSD.org>
To: root at ai1.alaska.net
Cc: FreeBSD-gnats-submit at freebsd.org
Subject: Re: standards/176412: newfs writes by default, compare to
bsdlabel/disklabel.
Date: Mon, 4 Mar 2013 15:47:34 +0100
On 2013-02-24 15:31, root at ai1.alaska.net wrote:
> >Number: 176412
> >Category: standards
> >Synopsis: newfs writes by default, compare to bsdlabel/disklabel.
>
> fdisk/bsdlabel will not write to a drive by default, and require
> special options to do so, yet newfs will destroy an entire drive,
> easily and accidently, unlike other dangerous utilities. This can
> cause severe problems when a user only wants newfs to read and report
> superblocks, and in utilizing the command, may easily forget the -N
> option, whereafter, the user loses his entire drive and all data. It
> is also easy to be careless with newfs when previously, fdisk/bsdlabel
> are used without worry of accidental destructive writes to a drive.
>
> Play with newfs to read superblocks on a drive, and while
> experimenting with options, forget the -N option one time, and your
> drive and data are lost forever.
>
> It would be consistent with dangerous utilities like fdisk/bsdlabel
> for newfs to read by default, and only write when a user clearly
> demands such functionality. There is no good reason for newfs to
> operate otherwise. It's an accident waiting to happen, almost as if
> deliberately.
newfs is not the only utility that can 'write by default' on a raw disk,
possibly overwriting important data. dd(1), cat(1) and pretty much any
other tool that can be pointed at a disk can do the same. For instance
it's always possible to write the wrong disk number in commands like:
dd bs=4m if=imagefile.bin of=/dev/ada1
ssh remotehost 'cat imagefile.bin' | tee /dev/ada0
The -N option is fine in newfs as an equivalent of --dry-run in other
tools, but I don't think it makes sense to break compatibility with
almost 40 years of history just because it can be unsafe if misused.
More information about the freebsd-standards
mailing list