Re: [boost] [filesystem] directory_iterator may cause bufferoverflow

From: Takeshi Mouri (takeshi.mouri.net_at_[hidden])
Date: 2005-12-21 09:43:55

> >> See also:
> >> http://thread.gmane.org/gmane.comp.lib.boost.devel/115104
> >> http://womble.decadentplace.org.uk/readdir_r-advisory.html
> >>
> >> In the article above,
> >> calling readdir_r() after pathconf() has race condition,
> >> so it is necessary to secure the size that seems to be perhaps enough.
> >>
> 
> CVS head has now been updated.
> 
> --Beman 

Sorry, my explanation seems not to have been good.

> BOOST_FILESYSTEM_DECL boost::filesystem::system_error_type
> dir_itr_first( void *& handle, void *& buffer,
>   const std::string & dir, std::string & target,
>   status_flags &, status_flags & )
> {
>   static const std::string dummy_first_name( "." );
>   if ( (handle = ::opendir( dir.c_str() )) == 0 ) return errno;
>   target = dummy_first_name;
>   long pc_name_max( ::pathconf( dir.c_str(), _PC_NAME_MAX ) );
>   if ( pc_name_max == -1L ) return errno;
>   dirent de;
>   buffer = std::malloc( (sizeof(dirent) - sizeof(de.d_name))
>     + static_cast<std::size_t>( pc_name_max ) + 1 );
>   return 0;
> }  

When path 'dir' is a symbolic link,
the directories opened by opendir() and pathconf() might be different.
This is the race condition that I wanted to say. 

Though I think that this limitation is acceptable,
it is necessary to explain it in the document at least.

Another solution is to examine an accurate value
by using fpathconf() and the platform-dependent function
(ex. dirfd, fdopendir) as much as possible.
In the article above, Ben Hutchings recommends this.

Regards,
Takeshi Mouri