[KPhotoAlbum] Patch to speed up scanning for new images
Robert L Krawitz
rlk at alum.mit.edu
Sat May 12 01:16:31 CEST 2007
From: Shawn Willden <shawn-kimdaba at willden.org>
Date: Thu, 10 May 2007 22:33:31 -0600
On Thursday 10 May 2007 07:13:23 pm Robert L Krawitz wrote:
> You win some and you lose some. I understand the problem, but it
> doesn't sound like there's really a safe way around it, since
> KPhotoAlbum is threaded.
I don't think it's a such a large concern in this case. As long as
the system-defined MAXNAMLEN really is the maximum filename length
on the system, it's safe, no overflow is possible. And, actually,
it's even safer than that since you allocated sizeof(struct dirent)
+ MAXNAMLEN + 1 bytes, and struct dirent already allocates 256
bytes for the name. So, on my system, your code allocates 512
bytes, where no more than 256 should ever be needed. As the
security advisory Jan linked to says, some systems have a small
dirent structure, but the code should be safe even on those, as
long as MAXNAMLEN is correct.
For a little extra insurance, it might be a good idea to allocate
the data from the heap rather than the stack.
I'll make the change to allocate it on the heap, but quite frankly
this whole thing seems a bit silly. If MAXNAMLEN isn't correct, a lot
more things that readdir_r() will break. In fact, I think this whole
union thing is pointless, and I don't even remember why I did it in
the first place.
Yes, the binary will theoretically have portability problems, but
it's the same with any binary that was compiled on a system and used
on a system with different constants.
Robert Krawitz <rlk at alum.mit.edu>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
More information about the KPhotoAlbum