[osiris-devel] Hunting down lstat "bug" in scanner

[Douglas K. Fischer]

Hi Brian,

I've been doing some prelim work on hunting down what appears to be a
bug in the osirisd scanner. I have been getting spurious "error
conducting lstat on file" errors on scanning numerous hosts. What is
peculiar is that A) it is not always the same filenames or directories,
and B) the filename is always the form of PATH/CTL, where PATH is an
arbitrary path and CTL is a control char (\1, \2, etc, showing as ^A,
^B, etc).

>From what time I've had to work on this, I've run some basic straces and
found that the scanner process is indeed trying to lstat a file by this
name:

19109 lstat64("/var/lib/mysql/myisam/data/test/^B", 0xbffde810) = -1
EACCES (Permission denied)

and since it doesn't have perms to the directory hierarchy it is of
course then attempting rootpriv lstat-ing:

19109 write(3, "\3", 1)                 = 1
19109 write(3, "/var/lib/mysql/myisam/data/test/\2", 33) = 33

19105 read(4, "/var/lib/mysql/myisam/data/test/\2", 256) = 33
19105 lstat64("/var/lib/mysql/myisam/data/test/^B", 0xbffec6f0) = -1
ENOENT (No such file or directory)

which of course results in the error:

[503][dev01][err] error conducting lstat on file "/var/lib/mysql/myisam/data/test/^B"


So the point I'm at is trying to determine where the trailing control
char is coming from.

It appears that the errant filename is attempted after all of the
existing entries for a directory have been completed. An strace of the
getdents() call does not show any garbling of the dirents, nor is there
an extra one that would account for the errant entry. As a sanity check
I'm going to verify that there are no filesystem problems, etc.

Does any of this ring a bell?

Thanks,

Doug