peter@thirdi.UUCP (Peter Rowell) (05/20/88)
If the following command does not look Evil to you, then read on....
dump 0usf /dev/rmt0 /dev/rrf0g
I post this to the net in the hopes it will save someone else from
nailing themselves to the cross like I did. I am sure that more than
a few people will read this and say.
"Oh sure, *I* knew that's what would happen. Why didn't you:
(a) RTFM (read the friendly manual) (b) be more careful."
Well, actually, I *did* just RTFM and then I made one simple little
error and Murphy stepped all over my file system.
In case you haven't already figured it out, the command in
question (dump 0usf /dev/rmt0 /dev/rrf0g) will wipe out the
file system residing on device /dev/rrf0g! (Yes, it really did...)
The problem is that the "s" flag is looking for a size specification for
the tape (which I accidently left out). It apparently ate "/dev/rmt0"
and decided that it liked that just fine. Next, the "f" flag says "Oh
boy! I get to do the dump TO /dev/rrf0g". Now, it would have been nice
if dump had complained that I had not told it what device to dump FROM,
but Nnnoooooo, the manual says:
" ... If no arguments are given, the key is assumed to be 9u and a
default file system is dumped to the default tape. ..."
^^^^^^^^^^^^^^^^^^^
The default on my system (an ISI box running 4.3) is /dev/rsd0g. Since
this is a valid device on my system, dump promptly started dumping /usr
all over rrf0fg.
I saw right away that I had left the length off and interrupted the dump.
When I started it up again (with the length) it informed me that the
super-block was now caca and that I should run fsck with the -b switch.
I did this with -b 32 and -b 11600 and -b etc. etc. etc. sigh.
(Through no fault of my own, we did have a recent dump to restore from.)
In conclusion:
I *know* that being root is dangerous. I just never expected that
I could *create* a dead file system by using dump!
I personally would like to see dump modified along these lines:
1. Not default *anything* (except, perhaps, dump TO tape).
2. Be pickier about what a valid numerical value is.
3. Require confirmation for dangerous target devices.
(Such as mounted file systems or things in /etc/fstab.)
--------------------------------------------------------------------------
Peter Rowell "He's dead, Jim."
Third Eye Software, Inc. ...!pyramid!thirdi!peter
(415) 321-0967bzs@bu-cs.BU.EDU (Barry Shein) (05/25/88)
Although the problem you point out is clearly a misfeature/bug (dump not checking its arguments carefully enough) I think a better approach would be to write shell or c programs to act as wrappers and thus can be customized to do whatever checking (including local heuristics) you want. Part of the problem (eg. the rm * problem etc) is that people seem to assume that every command (particularly ones used by priv'd accts) must be used exactly as is and should have been developed to work as such. To some extent you're right and it's always a judgement call, but in terms of dumps I would consider the /etc/dump command just another operator like if[] or echo to use to write a command script around, typing directly into memory and jumping to zero has its hazards. Note: I don't advocate REPLACING commands or presenting wrappers as fundamentals, but with some commands (particularly complicated ones like dump) shell scripts can do much more to cure the problem you encountered than hacking in a little more arg checking code to the original command. -Barry Shein, Boston University
karish@denali.stanford.edu (Chuck Karish) (05/26/88)
In article <22872@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >Although the problem you point out is clearly a misfeature/bug (dump >not checking its arguments carefully enough) I think a better approach >would be to write shell or c programs to act as wrappers and thus can >be customized to do whatever checking (including local heuristics) you >want. I agree. I've already done this, for dump. Several years ago, a couple of us wrote a C program that was designed to have setuid access codes, and be run by trusted-but-not-necessarily-skilled operators, who have group execute access. I'll mail it to anyone who wants it. Chuck Karish ARPA: karish@denali.stanford.edu BITNET: karish%denali@forsythe.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish USPS: 1825 California St. #5 Mountain View, CA 94041
mcneill@eplrx7.UUCP (Keith McNeill) (05/26/88)
I once did:
dump 0uf /dev/rra0a /dev/rra0a (blush)
My fingers just got carried away....
I like what sys5 dangerous utilities (volcopy & mkfs) do.
They tell you what you are doing and wait 5-10 seconds
before they do anything. This gives you a chance to
change you mind. For example dump could do something like this:
DUMP: Date of this level 0 dump: Thu May 26 09:03:42 1988
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rra0a (/) to /dev/rra0a
DUMP: Sleeping 10 seconds...Hit BREAK to quit....
Something like this would have saved us a morning of down time!
--
Keith D. McNeill | E.I. Dupont Co.
uunet!eplrx7!mcneill | Engineering Physics Lab
(302) 695-7395 | Wilmington, Delaware 19898
| Mail Stop: E357-302chris@mimsy.UUCP (Chris Torek) (05/28/88)
In article <611@eplrx7.UUCP> mcneill@eplrx7.UUCP (Keith McNeill) writes: >I like what sys5 dangerous utilities (volcopy & mkfs) do. >They tell you what you are doing and wait 5-10 seconds >before they do anything. This gives you a chance to >change you mind. ... The old `restor' program (no `e') did this for `restore r'. This sort of `countdown to disaster' is fine in its place, but that place does not include something that is done often (e.g., several times a day for /etc/dump). When you do something often enough, you wind up doing it by rote: >DUMP: Date of this level 0 dump: Thu May 26 09:03:42 1988 >DUMP: Date of last level 0 dump: the epoch >DUMP: Dumping /dev/rra0a (/) to /dev/rra0a >DUMP: Sleeping 10 seconds...Hit BREAK to quit.... Chances are that, after a few months, the operator would not notice anything odd about this until the dump finished. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jgp@moscom.UUCP (Jim Prescott) (06/10/88)
In article <406@thirdi.UUCP> peter@thirdi.UUCP (Peter Rowell) writes: >... >In case you haven't already figured it out, the command in >question (dump 0usf /dev/rmt0 /dev/rrf0g) will wipe out the >file system residing on device /dev/rrf0g! (Yes, it really did...) >... >I *know* that being root is dangerous. I just never expected that >I could *create* a dead file system by using dump! Nor did I expect to wipe out our file system with fsck (in preparation for a dump 0 no less). On our pdp11 running V7 I typed: fsck -c -t/tmp/foo /dev/re and wondered why it started checking /dev/rusr. Turns out that the the temp filename MUST be a separate argument. It ignored the /tmp/foo and used /dev/re for its tempfile while it checked things out of /etc/checklist. Fortunately it didn't overwrite any data, just the superblock and the first 167 blocks of inodes :-( I just tried the same on a 3b2 and it seems that a check for the type of the tempfile got added somewhere along the line. Seems reasonable that programs that expect files systems as arguments do a little more sanity checking of arguments than normal. At least we had backups. (Actually the only backups were dumps done on live (but quiescent) filesystems. I had been unsuccessfull in convincing anybody that at least doing the dump 0's on unmounted filesystems was worthwhile. All 3 dumps loading ok without even any warning messages. This didn't do much for my fight for clean dumps :-). -- Jim Prescott moscom!jgp@cs.rochester.edu {rutgers,ames,cmcl2}!rochester!moscom!jgp