Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
OS X Businesses Operating Systems Apple

Silly Kernel Panic in Mac OS X 10.2.2 192

Posted by pudge from the don't-try-this-at-home dept.
shibby tells us that it is easy to cause a kernel panic in Mac OS X 10.2.2, by attempting to move a directory into the same location as another one of the same name, using Terminal: mkdir ~/mydir; cd ~/mydir; mkdir mydir; mv mydir ... Kernel panic is instant. Save all your documents and quit your open apps if you feel the need to see it for yourself. Happy Thanksgiving!
This discussion has been archived. No new comments can be posted.

Silly Kernel Panic in Mac OS X 10.2.2 More

Silly Kernel Panic in Mac OS X 10.2.2

Comments Filter:

  • Wow (Score:3, Funny)

    by darkov ( 261309 ) on Friday November 29, 2002 @09:59AM (#4779529)
    Apple has a bug. This is amazing news. FP

    • Re:Wow (Score:2, Funny)

      by Anonymous Coward
      Isn't it called a 'worm' there?

    • Why? (Score:1, Troll)

      by 0x0d0a ( 568518 )
      Apple has a bug. This is amazing news.

      I'd say it's pretty notable. Apple's never been noted for particularly buggy code, though OS X has had a fairly nasty number of things like kernel oopses since its introduction. So while it's not *that* out of line for issues to pop up in a youthful OS, the amazing thing is that this didn't show up before. /me thinks Apple would have been better using someone else's kernel -- like the FreeBSD one -- verbatim instead of trying to hack up that Mach POS (which I've heard nothing but bad things about from OS people up at Carnegie Mellon, where Mach was developed). They could still have plopped Carbon and Quartz and all their other goodies on top.

      Of course, I certainly could be missing something -- could be that the FBSD kernel just didn't do something that Apple had to have it do, and that the FBSD people wouldn't have accepted. Could be SMP issues, I suppose...

      • Re: Why? (Score:2, Interesting)

        by capmilk ( 604826 )
        You could not note this bug before, because it was introduced in 10.2.2. Let's hope it will be gone in 10.2.3.

      • Re:Why? (Score:2, Funny)

        by susehat ( 558997 )
        because they already had it! it was not "hacking up" , they just removed all 4.3BSD Tahoe code from it and added IOKit to the mix. XNU is very stable, and it would not make any sense to go with any other kernel, since you lose a lot of the goodies that made it so powerful. Wishful mod to you: 1, trollbait

      • Re:Why? (Score:4, Informative)

        by stripes ( 3681 ) on Friday November 29, 2002 @02:45PM (#4780668) Homepage Journal
        Apple would have been better using someone else's kernel -- like the FreeBSD one -- verbatim instead of trying to hack up that Mach POS (which I've heard nothing but bad things about from OS people up at Carnegie Mellon, where Mach was developed).

        Well MACH isn't exactly an OS, it is more of an OS for running OSes, and one of the OSes it can run is the "BSD Single Server" which is a BSD4.3+/4.4ish derieved OS that isn't in my opnion as good as some of the other BSD4.4ish derived OSes (like FreeBSD).

        One of the other OSes that runs under MACH is a modifyed MacOS9. I havn't run OS9 (aka "Classic") on purpose for months, but other people find it rather indepsnsable, and wouldn't use OSX without it.

        As you say they could plop Carbon and Quartz ontop of FreeBSD just as easally as onto MACH's BSD Single Server. However getting OS9 to "run under" FreeBSD would have been a much larger pain.

        Of course, I certainly could be missing something -- could be that the FBSD kernel just didn't do something that Apple had to have it do, and that the FBSD people wouldn't have accepted. Could be SMP issues, I suppose...

        I doubt it is SMP issues. I'm not even sure the FreeBSD people would reject the stuff needed to get OS9-under-FreeBSD working, after all it might not be that different from what WINE needs from the kernel...but it would have taken a whole lot more time then getting OS9 running under MACH more or less along side the BSD Single Server (kind of under it and off to one side I susspect...)

        the device driver model is also different, and in a lot of ways better (and unfortunitly in a lot of ways worse) then FreeBSD.

      • Re:Why? (Score:5, Interesting)

        by Elwood P Dowd ( 16933 ) <judgmentalist@gmail.com> on Friday November 29, 2002 @03:25PM (#4780851) Journal
        Well, Avie Tevinian [apple.com] probably doesn't agree with your "OS people up at Carnegie Mellon", and he's running the show over at Apple. He also wrote some pertinent versions of Mach, up at Carnegie Mellon.

        When it comes to questions like this, if you can get the best people, using their prefered tools is often a good idea. If Apple could have hired all the architects of the freebsd Kernel, then sure, maybe you'd be right.

        Also, I don't know what the hell you mean that you've "heard nothing but bad things about" Mach. It's a well known and well inspected peice of code. It might have problems, but saying "bad things" doesn't mean anything. What are the problems? Message passing is slow? This is true. Whatever. It's an architectural choice. Some of those architectural choices are exactly what makes Mach good for Apple - Multiple OS hosting.

      • Re:Why? (Score:3, Interesting)

        by KnotMe ( 618202 )
        This looks more like the result of Apple's notably difficult attempt to get Unix to work with HFS+ than any problem with their kernel design.

  • I hope you submited to Apple (Score:5, Insightful)

    by feldsteins ( 313201 ) <scott@@@scottfeldstein...net> on Friday November 29, 2002 @10:09AM (#4779557) Homepage


    Please tell me that shibbey or pudge...or someone... actually submitted this bug to Apple before posting it here.

    It'll be interesting, though, to see how long we wait for a fix. If this is a legit thing. I haven't tested it and don't plan to.

  • C|/CON/CON (Score:3, Insightful)

    by isorox ( 205688 ) on Friday November 29, 2002 @10:11AM (#4779565) Homepage Journal
    This is as dumb as the windows file/run/file://C|/CON/CON doohickey.

    Can this be exploited by a rouge shell script? "Funny_Picture.png.sh" wouldnt be fun, given the average mac user is
    1) As guilable as windows users
    2) Not as savvy to the ways of trick emails as windows users.

    At least it wouldnt propergate - I assume theres a undered different mail clients on OSX. (I'm not a millionaire and cant afford my own mac you insensitive clod!)

    • Re:C|/CON/CON (Score:5, Funny)

      by sweet reason ( 16681 ) <mbloore@yaho o . com> on Friday November 29, 2002 @12:13PM (#4779976) Homepage
      Can this be exploited by a rouge shell script?

      i don't think so, but a big blue one could do the job.
      • He He He He

        The color of the shell script depends on your terminal settings or your syntax highlighting editor. Big blue shell script would imply VIM with the blue color theme. I prefer my shell scripts to be black and white . . . funny results come from all the grey areas.
    • OS X comes with iMail, a very capable and slick mailer that I'm sure 90% of Mac buyers use. We might see a sploit for it, but the Unix permisions will keep it from being too bad (i hope).

      This is definiatly an exploitable bug, but it's not root access, and any code useing it would be easy to fix.

    • Re:C|/CON/CON (Score:3, Insightful)

      by derch ( 184205 )
      Don't know about the other two major mail clients (Eudora and Entourage), but Mail wouldn't trick users into double clicking a hypothetical "Funny_Picture.png.sh."

      Shell scripts by default are associated with TextEdit. Double clicking on an attached shell script would open it in the editor. No execution. No harm.

      As long as the other two mail apps follow the system's file association, all's well.

  • Its not a bug (Score:5, Funny)

    by WesG ( 589258 ) on Friday November 29, 2002 @10:24AM (#4779602)
    Not only does it cause a kernal panic, but it slaps the user on the head and asks them, "Why the heck did you create a directory with the same name as the current directory????"

    Those crazy kernal programmers :-)

    • It could be several bugs, but it isn't clear. Does the same thing happen if you aren't moving the directory to itself as in the example? mkdir x y mv x y

      Should leave you with subdir y containing subdir x, but 'mv x x' is an error. If the code for mv actually tries to treat 'mv x x' like 'mv x y' (x and y are directories), then it will be badly breaking the rules for using link(2) and unlink(2).

      Although it isn't a particularly deep bug, the fact that it panics makes it pretty nasty. What I would be curious about it how/where it was introduced. None of the code involved should be special to Apple in any way, so what happens on BSD (probably gives you an error, right?). Linux gives: "mv: cannot move `x' to a subdirectory of itself, `x/x'", and I'd be very surprised that BSD doesn't do the same, so how did it get broken.

      • Still, in Linux it just gives you an error message, or does what you would expect. I'm still curious about the origins of this bug, and where it is. I would look at the 'mv' command code first.

      • FreeBSD 4.6-RELEASE (GENERIC) #0: Tue Jun 11 06:14:12 GMT 2002
        Welcome to FreeBSD!
        [Z:~] I% mkdir x
        [Z:~] I% cd x
        [Z:~/x] I% mkdir x
        [Z:~/x] I% mv x ..
        mv: rename x to ../x: Directory not empty
        [Z:~/x] I% cd ..
        [Z:~] I% mv x/x .
        mv: rename x/x to ./x: Directory not empty

        Names changed to let the guilty run away scot-free...

      • Re:Its not a bug (Score:3, Informative)

        by stripes ( 3681 )
        None of the code involved should be special to Apple in any way

        Mac OSX by default uses HFS+ rather then FFS, so there is a lot of Apple-specific code getting executed in there. Maybe they don't do namei cache invalidation correctly in their HFS+ file system code (for example).

        Not a huge unforgivable bug to have, but one hopes they will try to fix it quickly. It would definitly re-enforces my opnion of OSX as very stable for a desktop OS, but not very stable as a server OS. Which is why I own an Apple laptop, but not an Apple rackmount computer ;-)

        However if they don't fix this kind of bug fast they are less likely to sell Xserve systems...

        ...not that Sun didn't have a bug where if you ftruncate'd /dev/audio you got a panic for something like five years! Sure that is a little less serious because you could deny users access to /dev/audio on a share machine and not suffer, but still... and I think it worked on any streams object that lived int he file system, so....

        ...but it would be nice if Apple proved themselves to be better then that.

    • threaten a Congressional investigation into his mens' use of military-issued credit cards.

      oh, wait, that's a Colonel....

  • Ooops (Score:5, Funny)

    by iMMersE ( 226214 ) on Friday November 29, 2002 @10:32AM (#4779625) Homepage
    Found the offending piece of code in Darwin ...

    BOOL HFSPLUS_Directory_Move( const char *src, const char *dest ) {
    if ( !strcmp( src, dest ) ) {
    __kernelPanic( KP_IMMEDIATE );
    } ...
    }

    • Re:Ooops (Score:4, Informative)

      by Gerry Gleason ( 609985 ) <gerry@geraldgl[ ]on.com ['eas' in gap]> on Friday November 29, 2002 @11:01AM (#4779740)
      Except that string comparisons aren't particularly useful in deciding that two directory arguments are the same. You have to stat them and compare inodes and devs.

      Yes, I know this is trying to be funny, but on /. accuracy counts in humor as well.

      • I think you'll find checking string arguments would be a hell of a lot more useful than checking inodes in this case.

        mkdir ~/mydir; cd ~/mydir; mkdir mydir; mv mydir ..

        You are moving a directory in your pwd to it's parent. If the directory you are moving has the same name as the directory you are in, you get a kernel panic.

        You're right, accuracy counts :)
        • I'll admit to a little initial confusion about the example case, but still, string compare of the args doesn't get you anything. For 'mv' the usage case is moving a directory to an existing directory, which is a reduced case of 'mv [...] ' (moving a list of files and/or dirs to a dir). If the source is a file, you replace a file of the same name, but if there is a directory in the target dir matching the source name (just the basename part), then it should be an error whether the source is a file or directory.

          Now, the issue WRT this now too long thread about a bad joke, is that the test is for existence of a dir in the target dir, not string comparison, or inodes (that's another case that may or may not work correctly).

  • First there was General Controls, who was sometimes drunk and forgot all my preferences.
    Then there was Colonel Panic, who wouldn't work if you added two folders with the same name to the same in box on his desk.
    What's next? Private Keychain will forget where he stored my passwords and x.509 certificates?
    Oh wait... you were talking about kernels...
    Sorry!
    -wjc.

  • IMPORTANT! (Score:5, Informative)

    by iMMersE ( 226214 ) on Friday November 29, 2002 @10:56AM (#4779726) Homepage
    Be very careful with this - If you are testing, or accidentally gonna do this, you will lose both directories and all data in them.

  • Works just fine on my system.... (in Bash, though) (Score:4, Interesting)

    by ewwhite ( 533880 ) on Friday November 29, 2002 @10:58AM (#4779733) Homepage
    I was able to create a directory and move a directory of the same name into it. Bash is my default shell. Try the same thing in Bash. exx@eddy:~/mydir/mydir$

  • They know .... (Score:5, Informative)

    by Draoi ( 99421 ) <draiocht&mac,com> on Friday November 29, 2002 @11:13AM (#4779786)
    This was originally posted to the darwin-development mailing list, of which I'm a subscriber;

    Here's the message [apple.com] (login: archives, pass: archives)

    This list is teeming with Apple folks, so I'm sure someone's posted a RADAR bug already.

    This problem also came up on MacNN and is discussed in detail here [macnn.com]

    Now here's the kicker - as the kernel is open-source (APSL - don't complain), someone's already traced the problem back to a recursive lock in the HFS+ subsystem (hfs_vnops.c). Kewl or wha'?

    • Re:They know .... (Score:3, Insightful)

      by longbottle ( 537395 )
      Kind of OT, but what the hell.

      When is Apple finally going to overhaul HFS+? It's a decent filesystem, but it has quite a few drawbacks and limitations, including this "issue", if what you say is true.

      Microsoft finally did right and made NTFS the standard. BeOS has BFS, and Linux... well, there's about 10 good filesystems for Linux.

      HFS+ has been around since the early days of multigigabyte hard disks. In computer time, that's an eturnity. Come on Apple, the time has come for HFS++.

      • Re:They know .... (Score:2, Informative)

        by slughead ( 592713 )
        you can use UFS for OS X.. about a quarter of all programs (and all MS programs) can't take that whole "case sensitivity" thing.. and neither can I

      • Re:They know .... (Score:4, Informative)

        by Space Coyote ( 413320 ) on Friday November 29, 2002 @02:41PM (#4780644) Homepage
        Apparently one of the reasons Apple has delayed the release of their XServe RAID product is so that they can completely re-write HFS to include journalling and other such niceties. I don't care just as long as they don't take away the stuff that we all love about Mac file systems.

      • Re:They know .... (Score:1, Informative)

        by Anonymous Coward
        HFS+ has been around since about '98 with the releas of Mac OS 8.1 which is a long time, but not that long... I am not sure which drawbacks you are thinking of, really. This bug is just that, a bug, not an aspect of the filesystem. Case insensitivity is az feature, and will never be dropped. If the filesystem became case sensitive that would be viewed as a bug.

        It is pretty clear that Apple is working on the filesystem. They hired some Be people who worked on BFS, and just released Jornaling with 10.2.2.

      • What's wrong with HFS+? (Score:5, Informative)

        by 2nd Post! ( 213333 ) <gundbear@pacbe l l .net> on Friday November 29, 2002 @03:59PM (#4781003) Homepage
        What's missing that you want HFS+ to go away or something?

        It's got metadata, which Microsoft only *added* with NTFS
        It finally got journaling with 10.2.2
        It spans, quite comfortably, 180GB hard drives
        File sizes can be larger than 2gb, and I believe up to 2TB (2^63 bytes per file)

        Is there something missing? Perhaps encryption? Apple already has support for encrypted volumes...
        • POSIX compliance would be nice. I know it's not going to happen, but it would be nice - for a Unix to not be POSIX-compliant is really quite a black eye for IT departments. This is one of the few areas where Apple failed to successfully blend the needs of Unix users with the needs of desktop consumer users.

          Yes, you can use UFS filesystems under Mac OS X, but many Carbon apps, not to mention Classic, will fail to run - and the argument for using a Mac is substantially weakened if you're not going to be able to take advantage of the commercial software out there for it.

  • ArsTechnica (Score:5, Informative)

    by Draoi ( 99421 ) <draiocht&mac,com> on Friday November 29, 2002 @11:23AM (#4779813)
    .. have a thread going on this, too. Link here [infopop.net]

  • Could it be a copyright problem ? (Score:5, Funny)

    by Anonymous Coward on Friday November 29, 2002 @12:25PM (#4780026)
    Isn't "mydir" a Microsoft innovation? Could explain why it crashes ;p

  • smb bug? or maybe i'm an idiot (Score:3, Interesting)

    by drive ( 621617 ) on Friday November 29, 2002 @01:03PM (#4780167)
    perhaps off topic, but it will also cause kernel panic (at least in my network without fail).

    try to mount a share from an local smb server that does not exist. cancel it, then try to mount one that DOES exist.

    ie. from the finder command-k
    smb://10.0.1.3 #does not exist
    cancel it,

    smb://10.0.1.4 #does exist

    the second attempt will time out and the machine will have to be hard reset.

    maybe this is just me, but this has been happening to me since 10.1.5
    • Better yet... If samba has shared user directories try this: Mount username's samba share (ie home directory) in ~/mnt/username/ Now try to cd ~/mnt/username/mnt/username/mnt/username Make sure you use some tab completions as well. At some point you will no longer be able to continue typing the command. ^C wont stop it either. Ok, so you now want to unmount it to try and stop it from happening again. Good luck. umount ~/mnt/username will end up locking up as well. Yet again ^C wont stop it.

  • Fink/GNU is your friend (Score:5, Insightful)

    by bluestar ( 17362 ) on Friday November 29, 2002 @01:16PM (#4780207) Homepage
    Sure enough using /bin/mv it crashed as advertised.

    But /sw/bin/mv, which is the GNU version of mv from the fileutils package, just gives a "cannot overwrite directory" error.

    This is (one of the many reasons) why the GNU versions of everything should be standard on all systems in the universe. So go fetch and install a copy of fink and (optionally) FinkCommander.

    Also, "alias mv mv -i" is a Very Good Idea(tm).

    • Re:Fink/GNU is your friend (Score:1, Insightful)

      by Anonymous Coward
      That will not fix the problem. if a software use the Rename system call, the kernel will crash anyway. Even with the GNU vesion of mv
    • This is (one of the many reasons) why the GNU versions of everything should be standard on all systems in the universe.

      No, it is not. While there are good reasons to prefer some GNU tools to some other tools under some circumstances, this is a bug that will be fixed soon enough. A user program should not be able to crash the kernel, and the fact that GNU mv seems to do some checks up front doesn't mean that it's actually better in any way (it might be better in other ways, however).

      Also, "alias mv mv -i" is a Very Good Idea(tm)

      No, again, it isn't. It gives you the habit of believing that mv is really mv -i. So whenever you use someone elses account, or are working on some other machine, you risk doing something really stupid.

      Besides, I happen to quite often use a shared development account that for hysterical raisins have set exactly this alias in it's startup files. I've yet to find a time where it has been more useful than annoying, and I doubt I'll ever find it. If you are worried about deleting stuff, use backups.

    • but the GNU version cannot rename files where the names only differ in case and that is where the bug is.

  • Cool. (Score:5, Funny)

    by red5 ( 51324 ) <gired5@gm a i l.com> on Friday November 29, 2002 @02:12PM (#4780512) Homepage Journal
    You should see the death screen. Very slick. I'd post a screen grab, but well you know. :)
  • I bulit and installed GNU fileutils 4.1 on my Mac OS X system some time ago (I wanted my Linux flavored fileutils!) and it turns out that they (mv) don't have this ...mv dirname .. problem. Try it!

  • journalling (Score:2, Insightful)

    by owenc ( 255848 )
    It would be smart to enable journalling before doing this:
    sudo diskutil enablejournal /
  • This page [entropymine.com], a browser test page for png images, instantly crashes IE on Jaguar. Kind of funny considering that IE on OS X has far better png support than the windows version.

    Overall, I've found OS X to be a wonderfully stable product, and have never seen a kernel panic.

  • Don't you get it? (Score:3, Interesting)

    by WebBug ( 178944 ) on Friday November 29, 2002 @07:18PM (#4781680) Homepage Journal
    I must admit to being somewhat taken aback by the comments here . . .

    While this bug appears trivial it is not.

    Consider: An entire apple server can be totally killed requiring a human to reboot it just by getting a totally unpriveleged shell access.

    EVEN A GUEST can kill the system using this simple simple set of commands. That's not good. Of course it's not the end of the world either.

    anyone know of a way to get unprivileged access on an apple server of your choice?!

  • Another easy one (Score:3, Interesting)

    by Wesley Felter ( 138342 ) <wesley@felter.org> on Friday November 29, 2002 @07:49PM (#4781752) Homepage
    Try changing an Ethernet interface's MAC address using ifconfig. Whoops.

  • I was able to cause a panic in 10.1.x by simply moving all files out of the root of an SMB share on a foreign host from the Terminal. I was able to duplicate at will, and did submit to Apple at one time.

    No problem copying and removing the files from the terminal (using the same filespecs). Only the "mv" command would do it.

    I have no idea of this was fixed in a later release of 10.1 or 10.2.

  • WARNING: SHUT DOWN YOUR FTP DAEMON (Score:4, Interesting)

    by Tokerat ( 150341 ) on Monday December 02, 2002 @05:49AM (#4791965) Journal

    I just tested this over an FTP connection to a Mac OS X 10.2.2 box using Transmit (a Mac FTP client) from a MacOS 9 machine.

    I was ABLE to panic the kernel remotely.

    This has just taken a violent swing into serious, as ANY USER WITH FTP ACCESS can now drop your Mac OS X machine. Apple needs to patch this, and quickly. I don't care if the security update is 15k to replace /bin/mv, anyone who has an FTP cannot live like this.

    Any idea what eactly could be wrong with either the kernel or mv that would cause such a problem? Branching to the wrong case (i.e. branching to the "same name" case as opposed to the "can't replace a directory with an item it contains" case)?

    Is this a job for the Darwin team since it involves a BSD component?

Slashdot Top Deals

"When the going gets tough, the tough get empirical." -- Jon Carroll

Close