Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Bug Operating Systems BSD

The 25-Year-Old BSD Bug 213

Posted by Soulskill from the better-late-than-never dept.
sproketboy writes with news that a developer named Marc Balmer has recently fixed a bug in a bit of BSD code which is roughly 25 years old. In addition to the OSnews summary, you can read Balmer's comments and a technical description of the bug. "This code will not work as expected when seeking to the second entry of a block where the first has been deleted: seekdir() calls readdir() which happily skips the first entry (it has inode set to zero), and advance to the second entry. When the user now calls readdir() to read the directory entry to which he just seekdir()ed, he does not get the second entry but the third. Much to my surprise I not only found this problem in all other BSDs or BSD derived systems like Mac OS X, but also in very old BSD versions. I first checked 4.4BSD Lite 2, and Otto confirmed it is also in 4.2BSD. The bug has been around for roughly 25 years or more."
This discussion has been archived. No new comments can be posted.

The 25-Year-Old BSD Bug More

The 25-Year-Old BSD Bug

Comments Filter:

  • more proof (Score:5, Funny)

    by Anonymous Coward on Sunday May 11, 2008 @10:13AM (#23369210)
    ...of the superiority of Microsoft.

  • the developers probably knew about it (Score:5, Funny)

    by Anonymous Coward on Sunday May 11, 2008 @10:15AM (#23369214)
    but they had more important things to do. At least until Balmer started throwing chairs.
  • Will we be hearing alot of "How did that get there?" as versions of BSD get patched up?

    That is, wouldn't somebody in the past quarter century have exploited this bug to hide a malicious executable file or two?

    Not sayin', just wonderin'...

  • See? SEE? (Score:5, Funny)

    by Frosty Piss ( 770223 ) on Sunday May 11, 2008 @10:21AM (#23369274)
    See? See?

    This is the power of Open Source!

    With all those eyes looking at the code, stuff like this gets ID'd and fixed LICKITY SPLIT!

    (runs and hides)

  • Trac (Score:5, Funny)

    by extirpater ( 132500 ) on Sunday May 11, 2008 @10:31AM (#23369348)
    Bug tracking software missed this because it's bug #1. lol.

  • Samba knew, but didn't pass it on? (Score:5, Insightful)

    by quarrel ( 194077 ) on Sunday May 11, 2008 @10:33AM (#23369362)
    The most telling thing in TFA for me was that the bug had been identified by the Samba team and a workaround implemented for Samba.

    Surely both the samba communities and the *BSD communities are active enough that this could have been passed on for further investigation by the *BSD crowd? (Sure, samba probably would still need a workaround, particularly given the long uptimes and widespread deployment of *BSDs)

    I know nothing of the devs at Samba and *BSD, but seems a bit strange. Perhaps they did try..

    Meanwhile, congrats to Marc on fixing a bug. One of the most touted benefits of open source (whatever your license) code.

    --Q

  • If no one has cared enough to fix it for 25 years, I'm guessing this should be rated as "inconsequential."

    Must have been a really slow news day at OSNews.

    • bug blassification, side effects and Insults! (Score:5, Funny)

      by JonTurner ( 178845 ) on Sunday May 11, 2008 @11:20AM (#23369634) Journal
      3 thoughts on this:

      1. I think this bug would be classified "archeological".

      2. The question now is what happens to the Samba work-around patches. Now that the bug is fixed, do the patches cause a side-effect (i.e. "a new bug")?

      3. This gives rise to a new meme of nerd insults. "You call yourself a programmer? Why I've fixed bugs older than you!" Of course, only one man is entitled to use that line.

      • 1. Excellent point! Wish I'd thought of it before submitting.

        2. It's still a feature that now will need remediation. Argues well against using work-arounds for long periods, rather than fixing the root problem. Think ITIL or Y2K.

        3. Actually others have solved older bugs, they just haven't had a slashdot article with their names in light. Think COBOL/FORTRAN.

      • Hmm, I fixed a dumb Direction Flag bug in an Intel C compiler in 1989. That same bug was recently recreated (and fixed a few weeks later) in GCC.

        If the GCC guys had access to the old Intel source code, would thay have made the same mistake?

    • Re: (Score:3, Insightful)

      by Goaway ( 82658 )
      Samba cared enough to implement a workaround.

  • BSD is Dying! (Score:5, Funny)

    by Doc Ruby ( 173196 ) on Sunday May 11, 2008 @10:44AM (#23369420) Homepage Journal
    If you define BSD as a collection of bugs, this story proves that BSD is dying.
  • After all it had survived for 25 years. Are we sure that it really is dead and did not just scurry away when the light was shined on it?

  • After this long (Score:4, Funny)

    by Hawkeye477 ( 163893 ) on Sunday May 11, 2008 @10:57AM (#23369486) Homepage
    After this long would this not be considered a feature? :)

  • Should it be fixed? (Score:5, Insightful)

    by CaroKann ( 795685 ) on Sunday May 11, 2008 @11:02AM (#23369520)
    Considering how old this bug is, and how much work-around code probably exists as a result, I wonder how many new bugs this bug fix will create.

    • Re: (Score:2, Insightful)

      by iamhigh ( 1252742 ) *
      Yeah, imagine if you had, like 90% market share, and your OS supported everything from 8 bit games to 64 bit collaborative applications... then it would be a real bitch to fix stuff.

      • Re: (Score:2)

        by andi75 ( 84413 )
        What the parent is hinting at is that Microsoft knows about a LOT of bugs in their operating system, but decided not to fix them, because that would break many many application already working around these bugs.

    • Re:Should it be fixed? (Score:5, Informative)

      by irc.goatse.cx troll ( 593289 ) on Sunday May 11, 2008 @11:43AM (#23369774) Journal
      Most workarounds involve disabling caching. As a result they could re-enable caching for a performance increase, but leaving it off should have no iller effects with the patch than without.

  • Known defect? (Score:2, Interesting)

    by oso ( 7152 )
    What really intrigues me is that this had been discovered, years earlier, by the Samba folk.
    Did the Samba folk not tell the BSD folk of the issue?

  • This couldn't have happened with Linux... (Score:3, Insightful)

    by Baumi ( 148744 ) on Sunday May 11, 2008 @12:04PM (#23369912) Homepage
    ...because currently, no Linux bug could possibly be older than roughly 17 years [wikipedia.org]. :-)

    • Re: (Score:3, Funny)

      by AlgorithMan ( 937244 )
      except for the code parts from Xenix (which is 28 years old) that was renamed to "SCO Unix" in 1989, which was - as we all know - stolen and illegally put completely into linux... (we have a suitcase full of evidence!!!)

      • Re: (Score:2)

        by Nimey ( 114278 )
        In other news, SCO stock has been sitting at $0.10 for days with minimal volume.

        http://finance.yahoo.com/q?s=SCOXQ.PK [yahoo.com]

      • Re: (Score:3, Funny)

        by driftingwalrus ( 203255 )

        except for the code parts from Xenix (which is 28 years old) that was renamed to "SCO Unix" in 1989, which was - as we all know - stolen and illegally put completely into linux... (we have a suitcase full of evidence!!!)
        And, no, you may not look within the Evidentiary Suitcase!

  • Long live the Code (Score:5, Interesting)

    by GuldKalle ( 1065310 ) on Sunday May 11, 2008 @12:37PM (#23370092)
    Am I the only one who thinks it's quite impressive to have 25 year old code still being used and employed on new systems?

    • Here is why (Score:5, Insightful)

      by Solr_Flare ( 844465 ) on Monday May 12, 2008 @12:12AM (#23374706)
      BSD and the *nixes were designed to be simple, effective, modular operating systems. As long as you have the drivers and know how, you can easily port them over and install them on a variety of hardware. Then, thanks to their modular nature, you can then plug in all the extra bells and whistles you need for your particular system and go to town.

      That is why they are still around and still popular. They are K.I.S.S., work as they are supposed to, and the modular code that is plugged into them can just be sloughed away when it becomes out dated, and newer, better code plugged in to modernize the OS as you go.

      That's also why Windows has had so many problems over the years. Windows was designed to be everything you need in a single package. That means everything is all tied up together. So, unlike BSD and the *nixes, when part of the OS becomes out dated, MS can't just unplug the old stuff and plug in new stuff. It's all interlinked from the ground up. That means a large portion of development time getting is spent fixing bugs caused by new additions, which then cause even more problems down the line when you go to update again. It also makes it bloated as legacy code ends up stuck in the mix because without it the patched together additions wouldn't function right.

      And, unfortunately for MS, their market dominance is based on the windows "feel" being familiar and backwards compatibility. If they could, I'm sure they'd re-write windows from the ground up, but now they are in a catch 22 where doing so might significantly kill their market share.

      I'm guessing Bill and company sometimes look back and kick themselves for not having the guts to go for broke and re-do the OS from the ground up for Windows XP. Because, back then MS was still king, Apple was at its low point with a very small and stagnant market share, and the *nixes were still primarily a hard core enthusiast hobby. Today, if MS were to completely change Windows, they'd probably lose a significant amount of market share to a variety of alternatives.

  • Another common old bug (Score:5, Interesting)

    by Solandri ( 704621 ) on Sunday May 11, 2008 @01:30PM (#23370394)
    Is the MPEG Chroma bug [hometheaterhifi.com]. That was created by someone who wrote one of the original MPEG decoders that was eventually sold/distributed to most of the companies making the first DVD players (pre-1993). This one just won't go away either - initially most of the DVD manufacturers refused to acknowledge it even existed (probably because they didn't want to recall millions of DVD players with non-upgradeable firmware). I still see it every now and then on TV (indicating one of the upstream broadcasting companies is still using equipment afflicted with the bug). I notice it most often when diagonal red lines end up staircased like they're poorly interlaced (see pictures in the above link).

  • Need a new system call to really fix this. (Score:5, Interesting)

    by m.dillon ( 147925 ) on Sunday May 11, 2008 @04:16PM (#23371632) Homepage
    The problem is that the stdio directory scanning routines cache multiple directory entries with a single getdirentries() system call, but then may try to 'seek' into the middle of that buffer later on.

    Any filesystem based on a non-linear-file directory format, such as a B-Tree, will simply never produce consistent offsets or indices within such a buffer.

    The only way to *REALLY* fix this is to add a cookie field to the filesystem-independant dirent structure (and if your BSD isn't using a filesystem-independant dirent structure, it needs to be first fixed to do that). lseek()ing to a directory cookie works just fine, and always will (or at least will far more robustly then trying to scan a re-cached buffer from getdirentries()).

    When DragonFly went to a filesystem-independant dirent structure I very stupidly only added ~40 reserved bits to the dirent structure, instead of the 64 we need to properly implement per-entry directory cookies. I'm still pissed at myself for that gaff.

    In anycase, a per-entry directory cookie effectively solves the problem. The only other way to get such cookies, if it can't be embedded in the dirent structure, is to create a new system call similar to getdirentries() but which also populates an array of directory cookies. FreeBSD and DragonFly have kernel implementations of readdir which supply per-entry directory cookies so it is really just a matter of creating the new system call and then making libc use it.

    -Matt

  • Demonstration of the bug (Score:5, Insightful)

    by ChrisDolan ( 24101 ) <chris+slashdot.chrisdolan@net> on Sunday May 11, 2008 @08:00PM (#23373152) Homepage
    The Perl program below demonstrates this bug. Tested only on OS X...

    #!/usr/bin/perl -w
    use strict;
    use File::Temp qw(tempdir);
    use File::Slurp qw(write_file read_dir);
    use Test::More tests => 9;
     
    # Create some temp files
    my $dir = tempdir(CLEANUP => 1);
    write_file("$dir/one", '1');
    write_file("$dir/two", '2');
    write_file("$dir/three", '3');
     
    # Confirm that the directory contains the files
    is_deeply([read_dir($dir)], ['one', 'three', 'two']);
     
    # Open a directory handle and read through all files
    opendir(my $dirh, $dir);
    is(scalar readdir($dirh), '.');
    is(scalar readdir($dirh), '..');
    my $file1 = readdir($dirh);
    is($file1, 'one');
    my $file2 = readdir($dirh);
    is($file2, 'three');
    # Record the position of the second file
    my $pos2 = telldir($dirh);
    my $file3 = readdir($dirh);
    is($file3, 'two');
     
    # Rewind to the second file's pos, and confirm that the next read is the third files
    seekdir($dirh, $pos2);
    is(scalar readdir($dirh), $file3);
     
    # Delete the first file and try the above test again. It *should* have the same results
    ok(unlink("$dir/$file1"));
    seekdir($dirh, $pos2);
    is(scalar readdir($dirh), $file3);
     
    closedir($dirh);
    The output of the program is:

    % perl bsdbug.pl
    1..9
    ok 1
    ok 2
    ok 3
    ok 4
    ok 5
    ok 6
    ok 7
    ok 8
    not ok 9
    # Failed test at bsdbug.pl line 30.
    # got: undef
    # expected: 'two'
    # Looks like you failed 1 test of 9.

  • OpenBSD is good at fixing this kind of bug (Score:4, Insightful)

    by chrysalis ( 50680 ) on Monday May 12, 2008 @04:30AM (#23375656) Homepage
    This is not the first time the OpenBSD time does an excellent job at finding obscure bugs that were lying around for one or two decades in every BSD derivative. Congratulations !

Slashdot Top Deals

C'est magnifique, mais ce n'est pas l'Informatique. -- Bosquet [on seeing the IBM 4341]

Close