On Wed, Jun 13, 2007 at 05:27:18PM -0700, Matthew Ahrens wrote:
> To summarize my understanding of this issue: st_size on directories is
> undefined; apps/libs which do anything other than display it are broken.
> However, we should avoid exercising this bug in these broken apps if
> possible.
>
> My question: What apps are these? I heard mention of some SunOS 4.x
> library. I don't think that's anywhere near important enough to warrant
> changing the current ZFS behavior.
As mentioned before, NetBSD's scandir(3) implementation was one. The
NetBSD project has fixed this in their CVS. OpenBSD and FreeBSD's scandir()
looks like another, I'll have to drop them a line.
I went hunting for more apps in the hundreds of ports installed at my
shop to see what our exposure was to the scandir() problem - much to
my surpise out of 700 or so ports, only a dozen or so used the libc
scandir(). A handful of mail programs had a vulnerable local
implementation of scandir() - looks like they copied UW's imap code which
was based on the 4.2 BSD code. It's not clear to me that those get used if
there's an OS implementation of scandir, but I'll write to them too.
Just did a quick check on the 700 or so open source programs that we've
ported to our hosts - greping for "st_size / 24" got me things like this:
ircii/ircii-4.4/source/scandir.c: arraysz = (stb.st_size / 24);
imap-uw/imap-2004/src/osdep/unix/scandir.c: nlmax = stb.st_size / 24; /*
guesstimate at number of files */
For my shop, it looks like the problem is limited to apps that
have local implementations of scandir(). One of our long-term goals
is to convert the rest of our fileservers to ZFS, so if there are
any more, I or my customers are bound to find them.
-- Ed
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
