From owner-freebsd-current Mon Jul 30 2: 3:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 88D2937B403; Mon, 30 Jul 2001 02:03:36 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: by bazooka.unixfreak.org (Postfix, from userid 1000) id 2B9203E28; Mon, 30 Jul 2001 02:03:36 -0700 (PDT) Received: from bazooka.unixfreak.org (localhost [127.0.0.1]) by bazooka.unixfreak.org (Postfix) with ESMTP id 1965C3C12B; Mon, 30 Jul 2001 02:03:36 -0700 (PDT) To: Kris Kennaway Cc: current@FreeBSD.org, phk@FreeBSD.org Subject: Re: md/mdmfs bugs In-Reply-To: <20010729185401.A642@xor.obsecurity.org>; from kris@obsecurity.org on "Sun, 29 Jul 2001 18:54:01 -0700" Date: Mon, 30 Jul 2001 02:03:31 -0700 From: Dima Dorfman Message-Id: <20010730090336.2B9203E28@bazooka.unixfreak.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kris Kennaway writes: > 1) For some reason, my mdmfs line in /etc/fstab always does a chmod > 777 /tmp at mount-time > > /dev/md0 /tmp mfs rw,-s=65536 0 0 I can't reproduce this. You say it "does a chmod"; does that mean you see it caling chmod(2) (see as in using truss(1), or the undocumented -X option), or is the symptom that it "winds up with mode 777"? Also, does it happen when you run mdmfs from the command line, and/or with directories other than /tmp? > 2) the -X debugging option to mdmfs isn't documented in the manpage Oops, will fix. > 3) The following sequence of commands will cause my -current box to blow up: > > Step 1: disklabel -r -w md1c auto ^ Disklabel wants the disk name, not the partition. This is still a panic(8)/hang(8) implementation, but it doesn't derive you of any functionality. > where md1 isn't a valid configured md instance. This command spits > out a driver_mistake console warning message > Step 2: mdconfig -d -u md1 > Step 3: Watch the console spew messages in an infinite loop until the > end of time (Step 3 is optional). This is actually a bug in the disk minilayer. md(4) is just the most convenient driver to exploit those bugs, which is why we don't see stuff like this happening with ad/da. Furthermore, this is actually an exception-handling bug, not a real functionality problem. Notice how you call disklabel with "md1c" as an argument, while disklabel wants the name of the *disk*, not the partition! What ends up happening is that disklabel tries to access "md1cc", which isn't valid. However, when subr_disk.c::disk_clone() parses the name to clone, it only parses it up to where it got all the information it wants (it wants the unit, slice, and partition). This means that asking it to clone "md1cKRIS" will work just fine (try it: ls -l /dev/md1cKRIS); the major/minor will be the same as md1c. How should this be handled? It can either strip off the extraneous parts, or it can do nothing. Either of these will remove the cause of the infinite loop (step 3). I've attached a patch that does the latter as a proof-of-concept. All that said, I probably just scratched the surface, and likely got a few points even doing that. I'm sure phk will find the "real" problem when he wakes up :-). Index: subr_disk.c =================================================================== RCS file: /ref/cvsf/src/sys/kern/subr_disk.c,v retrieving revision 1.41 diff -u -r1.41 subr_disk.c --- subr_disk.c 2001/05/29 18:19:57 1.41 +++ subr_disk.c 2001/07/30 08:42:25 @@ -82,6 +82,10 @@ continue; else p = name[i] - 'a'; + if (name[++i] != '\0') { + printf("WARNING: attempt to access %s\n", name); + return; + } } *dev = make_dev(pdev->si_devsw, dkmakeminor(u, s, p), To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message