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

[Douglas K. Fischer]

Bingo. I was readily able to replicate it, and the problem appears to be
with the exit conditions of osi_readdir(). The

if( dp->d_reclen <= 0 || dp->d_reclen > d->dd_len + 1 - d->dd_loc )

statement does not correctly catch the case when we've reached the last
dirent entry that was returned by the fetch. We need to look at dd_size
compared with dd_loc to determine if we've reached the end of the
fetched entries (from glibc readdir() code). The outcome is otherwise
determined by the contents of the buffer past dd_size. In most of the
cases the resulting next read would fail the above condition and exit
with NULL, or fail one of the other NULL-returning conditions. However,
in some cases the buffer contents were such that a non-NULL return resulted.

I've attached a version of osi_readdir() that should solve this, as well
as deal with the aforementioned case where we need to perform one or
more additional getdirentries() in order to get the rest of the dirents.
The code is very similar to the glibc readdir() code, so it should
behave is almost exactly the same manner.

I don't have access to a system with getdents() instead of
getdirentries(), so I can't vouch for correct operation of the
re-fetching with getdents(). However, I've attached a simple patch to my
version of osi_readdir() that will disable the re-fetching for
getdents() if it doesn't work. (Provided that the underlying system call
keeps the fd seek pointer at the end of the last read from getdents(),
this should work I believe.)

Also, the restructuring of the osi_readdir() loop resulted in the
exclusion of the IRIX #ifndef around the zero inode checking. This may
or may not cause the problem to return on IRIX. I didn't see anything in
the glibc code that was different for IRIX. Was it all versions of IRIX
or a specific one? I've attached another patch in case this does cause a
problem with IRIX.

Cheers,

Doug

Brian Wotring wrote:

> Attached is a sample application that makes use of osi_readdir() to
> traverse a directory and list the entries, the same way the privsep
> code does.
>
> -brian
>
> Brian Wotring wrote:
>
>> At this point, it makes sense to write a test app that makes use of
>> the osi_readdir() code to see if this problem can be duplicated.
>>
>> If I am unable to duplicate it, do you have a system that
>> demonstrates this problem that you would be willing to try to
>> duplicate it on? I'll post the app shortly.
>>
>> -brian
>


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: osi_readdir.c
Url: http://lists.shmoo.com/pipermail/osiris-devel/attachments/20050915/2a4ce091/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: osi_readdir-getdents.patch
Url: http://lists.shmoo.com/pipermail/osiris-devel/attachments/20050915/2a4ce091/attachment-0001.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: osi_readdir-irix.patch
Url: http://lists.shmoo.com/pipermail/osiris-devel/attachments/20050915/2a4ce091/attachment-0002.txt