[Xcb] [PATCH libXau] Avoid heap corruption when calling XauFileName from multiple threads.

Rami Ylimäki rami.ylimaki at vincit.fi
Tue Mar 29 02:06:34 PDT 2011


On 03/28/2011 09:14 PM, Mark Kettenis wrote:
>> Date: Mon, 28 Mar 2011 10:21:06 -0700
>> From: Alan Coopersmith<alan.coopersmith at oracle.com>
>>
>>> This commit fixes only the heap corruption and sporadic crashes. It's
>>> still possible that XauFileName returns a badly formed filename string
>>> if called from multiple threads. For example, changing contents of
>>> HOME environment variable could make the returned string to be
>>> malformed. However, there shouldn't be crashes.
>> Perhaps we just need to define a new function to do this, that doesn't
>> use a static global variable of any sort, and declare that multi-threaded
>> code needs to use it.
> That does make more sense than adding hacks to limit the potential
> damage.  The current interface simply is inherently thread-unsafe.

I was actually thinking about implementing XauGetFileName as an 
alternative for XauFileName, that would return dynamically allocated 
filename string and require it to be freed by callers. However, the real 
problem is that getenv has to be called at some point to get XAUTHORITY 
or HOME, and that can't be done safely inside a library in any portable way.

The only way to solve the problem in a thread safe manner would be to 
pass copies of XAUTHORITY and HOME to Xlib/Xcb when creating a new 
connection. Alternatively the semantics of connection creation should be 
changed so that environment variables would be completely ignored. Both 
of these options aren't very good from backward compatibility point of view.

We chose to fix the common case and make connection creation safe as 
long as environment is not modified at the same time. We didn't 
implement a new function, because if we offer a new function for 
multithreaded clients, it should be also protected against environment 
changes. That would again require a lot of changes in users of libXau. 
In other words, the fix avoids a real problem and while not perfect, 
it's good enough. 
[http://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good :)]

Could you give your opinion about the environment problem? If a new 
function is created for multithreaded clients, what should be done about 
reading XAUTHORITY and HOME in a safe manner? Alternatively, do you 
think that protecting against environment changes is not that important 
and fixing the allocation problems are enough?

-- Rami



More information about the xorg-devel mailing list