Re: Stack overflow in lsys_load (lua/loadlib.c:134)

[Viacheslav Usov <via.usov@...>]

On Mon, Sep 14, 2020 at 8:58 PM Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:

> 3) loadlib is inherently low-level and unsafe

It is certainly true that this function can be used to cause a lot of
harm even without the dlopen() issue. So trying to address this issue
in the context of only loadlib() does not make much sense.

On the other hand, require() seems to be immune to this, which I think
is due to the use of fopen() before it even tries to call dlopen().
Interestingly, fopen() seems to be able to deal with very long path
names on both Linux and Windows, even though, per the standard, it
should only be called with filenames not longer than FILENAME_MAX,
which is a relatively small constant on these systems. The C standard
uses peculiarly ambiguous language when talking about FILENAME_MAX, so
it is debatable whether undefined behavior could ever ensue.

So considering all this, I agree with you that this needs no fixing
except perhaps the following.

The word "unsafe" is not explicitly stated in the documentation on
loadlib(). And since it applies to a Lua-level API, the dangers may
not be so obvious to the reader. Especially to an inexperienced
reader.

I believe it would be beneficial to mark up "unsafe" Lua-level API
explicitly in the manual, and add a section with a shorter version of
the last paragraph of the "Sandboxing" section in PiL4 with a
reference to the "unsafe" markup. The intent is to guide the users
willing to embed Lua, but who are yet new to Lua.

Cheers,
V.