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

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

On Fri, Sep 4, 2020 at 8:47 PM Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:

> I know Linux and other systems have limits on actual file-name lenghts
> (e.g., PATH_MAX), but dlopen must accept non-existent file names, too.

Quite frankly, I find this very similar to a bug I recently reported,
wherein Lua originally permitted user code to pass arbitrary mode
strings to popen(), which, per POSIX, might lead to undefined
behavior. Your decision then was to reject any mode strings that were
not POSIX conformant by default, while giving Lua users a compile-time
option to override that behavior.

> I did not find any documentation saying that invalid file names
> (filename arguments, in particular) should respect that limit, too.

The file argument to dlopen(), per POSIX, is a "pathname" [1]. A
pathname is defined to contain at most PATH_MAX bytes, including the
zero terminator. A longer string would not be POSIX conformant. Your
decision now?

Cheers,
V.

[1] Unfortunately, it is more complicated than that. It is a pathname
only when it contains a slash, and when it does not, the whole thing
is implementation defined. I am not sure if Lua permits the user code
to require a library so that it leads to a slash-less file argument
passed to dlopen(), but I'd think at least by default it should not be
permitted when Lua is compiled in the POSIX mode.