Subject: [netatalk-admins] 1.4b2 (with Volumesize Patch) or +Asun Patch

From: Patrik Schindler <[email-masked]>
Date: Mon, 18 May 1998 00:16:04 +0200

Hi there!

I'm running Linux Kernel 2.0.33/libc 5.4.23 and Netatalk 1.4b2+asun2.0a18.2.

A BIG BIG warning for all who installed the Netatalk 1.4b2 with System 8 (CopyDoubler Patch) or ASun's Patches:

After scanning a remote volume with FileList (reads directories and its files and extracts version information if available) under System 7.5.5, my Syslog contained messages like these:

May 17 17:32:19 leela kernel: attempt to access beyond end of device
May 17 17:32:19 leela kernel: 08:12: rw=0, want=1145143375, limit=2029568
[...]
May 17 17:32:19 leela kernel: EXT2-fs warning (device 08:12): ext2_free_inode: b
it already cleared for inode 80425
[...]
May 17 17:32:19 leela kernel: EXT2-fs warning (device 08:12): ext2_free_inode: b
it already cleared for inode 80425
May 17 17:32:19 leela last message repeated 2 times
[...]
May 17 17:32:19 leela kernel: EXT2-fs warning (device 08:12): ext2_free_inode: b
it already cleared for inode 80425
May 17 17:32:29 leela kernel: EXT2-fs warning (device 08:12): ext2_free_inode: b
it already cleared for inode 80431
May 17 17:32:30 leela last message repeated 13 times
May 17 17:33:57 leela login[2078]: ROOT LOGIN ON TTY `ttyp3'
May 17 17:34:30 leela kernel: EXT2-fs warning (device 08:21): ext2_free_inode: b
it already cleared for inode 123651
May 17 17:34:38 leela kernel: EXT2-fs warning (device 08:21): ext2_free_inode: b
it already cleared for inode 123651

It may be of interest, that the actual device nodes in /dev do NOT correspond with Devices 8:12 or 8:21 (I do neither have sda12 nor sdb5).

After fscking these fs, (actual 8:18 and 8:33) they contained lots of errors. The first even had cross-linked files (I do NOT mean hardlinks). I don't have a log of these errors, but many directories have been "eaten", I remember a comment "Inode has ... zero. This can happen with old kernel code" or something similar. Many Entries "Entry .. in ??? blah blah...". The Questionmarks have been there!

Maybe somebody want's to fix this very ugly security hole of destroying unix FS via simply scanning a disk...

:wq! PoC

---

From: a sun <[email-masked]>
Date: Sun, 17 May 1998 18:13:53 -0700 (PDT)

May 17 17:32:19 leela kernel: attempt to access beyond end of device
   May 17 17:32:19 leela kernel: 08:12: rw=3D0, want=3D1145143375, limit=3D2029=
   568
   [...]
   May 17 17:32:19 leela kernel: EXT2-fs warning (device 08:12):=
    ext2_free_inode: b
   it already cleared for inode 80425

this has nothing to do with afpd. you're filesystem got hosed.

-a

---

From: a sun <[email-masked]>
Date: Sun, 17 May 1998 18:39:22 -0700 (PDT)

erk. that last message was a little too terse. here's what it should
have said:

	afpd did not hose your file system. most likely, your disk is
	going bad, or you mounted an unclean version of it. there is
        also the remote possibility that you've discovered a bug in
        the filesystem code. that one is the least likely.

-a

---

From: Patrik Schindler <[email-masked]>
Date: Mon, 18 May 1998 22:26:07 +0200

>this has nothing to do with afpd. you're filesystem got hosed.

Nope. The Filesystem has been definitively okay, I could verify these results!
The same program run on a netware-volume has no impact on it.

I think this is a VERY serious problem!

:wq! PoC

---

From: Patrik Schindler <[email-masked]>
Date: Mon, 18 May 1998 23:13:43 +0200

>        the filesystem code. that one is the least likely.

The first Disk is new and both are well-tested with NO defects. It's NOT the Disks. May anyone please try to verify my discovery on a test partition? I'm not programmer enough to say, what's exactly going wrong.

:wq! PoC

---

From: Osma Ahvenlampi <[email-masked]>
Date: 19 May 1998 10:44:42 +0300

Patrik Schindler <[email-masked]> writes:
> The first Disk is new and both are well-tested with NO defects. It's
> NOT the Disks. May anyone please try to verify my discovery on a test
> partition? I'm not programmer enough to say, what's exactly going
> wrong. 

I run Netatalk 1.4b2 + asun18a2.0 on a Linux 2.0.33 kernel system in a
production environment, with MacOS 8.0 and 8.1 clients. While
performance could be better (but I attribute this to inferior Ethernet
interfaces on the Macs, since pure TCP/IP traffic on them is slow as
well), I definitely have no problems with filesystem corruption. 

And while I don't have any intimate knowledge of ext2 or Linux
filesystem API (as opposed to the usermode file I/O API, which I do
know well enough) or Netatalk code (I've only looked at the
authentication code), as a programmer, I can't see how a program like
Netatalk could possibly corrupt a filesystem in the way you describe.

The log messages you see are caused by the ext2 filesystem detecting
existing corruption while processing Netatalk's I/O.

-- 
For a holy stint, a moth of the cloth gave up his woolens for lint. 
Osma Ahvenlampi <[email-masked]>

---

From: Mark Donnelly <[email-masked]>
Date: Tue, 19 May 1998 09:59:24 -0500 (CDT)

> The first Disk is new and both are well-tested with NO defects. It's NOT 
> the Disks. May anyone please try to verify my discovery on a test
> partition? I'm not programmer enough to say, what's exactly going wrong.

What I think that Adrian is trying to say is that it is impossible for
netatalk itself to hose your disks.  Let me explain, since (from your last
comment) you more than likely haven't had an operating systems class.

On any operating system with a good idea of "protection", (which Linux and
Rhapsody have, but MacOS and Win95 don't, which is why Norton's will never
really exist for Linux), any program that isn't the OS Kernel (vmlinux
itself) will not be able to issue instructions to touch the disk.
Instead, the "user programs" request that the kernel access the disk for
them, and then the kernel gets/puts the data, and sends a message (return
value) indicating the success.

So, I think that Adrian said that netatalk could not possibly have
corrupted your disks by itself.

That's not to say that netatalk had no fault in it whatsoever.  He pointed
out a couple of possibilities for what might have happened, one of which
you have ruled out (the disk being new).  The second is that the disk was
uncleanly mounted.  Did you recently have a power outage, or any other
reason that your box would have rebooted without going through all its
shutdown scripts?  The shutdown scripts on a UNIX box are very important.

The last possibility is the closest to what your conclusion was:  That
netatalk somehow issued a series of commands that caused the kernel to
hose the disk.  I realize that this is a matter of symantics (the kernel
hosed the disk on netatalk's behalf), but this is what Adrian meant by
saying that you might have found a kernel bug.  If neither of the first
options fit (and the first doesn't), then the proper course is to send a
mail to the kernel developers (I _think_ that Stephen Tweedie is the main
ex2fs person, but I'm not sure...look for e-mail addresses within the
code).  It should include the syslogs and as detailed description of your
system as possible.

Basically, there is nothing that netatalk should be able to do (besides
writing to /dev/hda, which I can't even concieve of happening) that should
be able to hose a filesystem.  Netatalk (as all UNIX programs) is built
on the assumption that the OS will prevent it from doing any damage,
especially if it just sticks to the standard system calls.  If netatalk
_is_ hosing it, then the kernel needs to be modified to not allow that.

Adrian, I hope I didn't put too many words in your mouth...
Patrik, I hope this clarifies a little.

--Mark Donnelly
    "I think so Brain, but if they called them sad meals, then nobody
        would buy them." 
   --Pinky

---

From: Richard Knuckey <[email-masked]>
Date: Wed, 20 May 1998 09:06:54 +1200

>>this has nothing to do with afpd. you're filesystem got hosed.
It sounds to me like the hard drive has not been corectly partitioned.
Either the BIOS has not correctly told linux what size the disk is, or
incorrect BIOS parameters have been entered in the BIOS at startup. A
partition has then been created that is larger than the disk, therefore the
errors trying to read beyond the end of the disk.

Another possibility is a conflict with your ethernet card and whatever
controls your hard drive. A IO port or IRQ conflict will meen that a write
request for ethernet could be handled by the Had drive controler, therefore
hoseing your drive.

The only thing which is certain is that it is not possible for netatalk to
directly hose the contents of your hard drive unless it deals directly with
devices rather than throughthe file system, which it doesn't do.

---------------------------------------------------------------------------
Richard Knuckey                                    [email-masked]
Technology Manager                                        DDI +649 573 5923
Techniche, a division of Blue Star Print Group Limited    Fax +649 573 1803

---

From: Patrik Schindler <[email-masked]>
Date: Wed, 20 May 1998 08:09:37 +0200

>It sounds to me like the hard drive has not been corectly partitioned.

This /could/ be. I partitioned this disk on an Adaptec 2840. Last week I upgradet to new hardware (and a 2940).

>incorrect BIOS parameters have been entered in the BIOS at startup.

The old and the new Adaptec have both extended translation disabled to get around such things. Oh, btw, it's NOT the boot-harddisk.

>A

Hmm, don't think.

>request for ethernet could be handled by the Had drive controler, therefore

Unlikely -> PCI.

>devices rather than throughthe file system, which it doesn't do.

Okay, thanks for your Advice.

I'm a little short of time, I've read the other answers (thank you all!) and I hope to get more into detail at the weekend.

:wq! PoC

---

From: Robert Edwards <[email-masked]>
Date: Thu, 21 May 1998 15:36:04 +1000

Patrik,

I have been following your woes silently for a while (you were initially
very insistent that there was a serious bug in netatalk - if there is, it
hasn't gotten me yet - :)

One thing I haven't seen anyone suggest, or you mention, is if you have
done an "fsck -f" on the problem filesystem recently? Surely if there is an
inode problem on the disk, "fsck" will find it and fix it? Does "dmesg"
show any "fsck" problems? Is the volume actually checked at system startup
(ie. if the entry in /etc/fstab has no numbers at the end like "2 2", then
it would default to "0 0" which means that fsck won't check the disk for
any inconsistencies).

Just my A$0.02 worth.

Bob Edwards,

Computer and Robotics Engineer,       e-mail: [email-masked]
Department of Engineering,            phone:  (+61) 2 6249 4090
Australian National University,       fax:    (+61) 2 6249 0506
Canberra, AUSTRALIA, 0200             mobile: (+61) 0416 166 761
      WWW: http://spigot.anu.edu.au/people/bob/home.html