Kris Kennaway <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to