Re: Meta function tables for LUA_FILEHANDLE: why two separate tables?

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

On Sat, Nov 19, 2022 at 12:30 AM Sean Conner <sean@conman.org> wrote:

>   I am wondering just how much of an issue this is.  Have you encountered
> Lua code that wantonly changed or called __gc() diretly?

"I am wondering just how much of an issue this is. Have you
encountered any code that wantonly overruns that stack-based buffer?"

> [1]     The only one I've seen is luafilesystem

I am unsure we are talking about the same thing. What I see at
https://github.com/lunarmodules/luafilesystem/blob/master/src/lfs.c
is, for example:

  lock = (lfs_Lock *) lua_newuserdata(L, sizeof(lfs_Lock));
  lock->fd = fd;
  luaL_getmetatable(L, LOCK_METATABLE);
  lua_setmetatable(L, -2);

This is the Win32 version of lock(), and, if __gc has been
obliterated, it will leak the handle of the lock file and fail to
delete the lock file. Thankfully, the Win32 "delete on close" flag
ensures that the file will be deleted when the process terminates, so
this is somewhat self-healing. Not so in the Posix version, where it
will never be able to lock the same file again, unless somebody cleans
up the lock file manually. Oh, and the Posix version also leaks the
entire path to the lock file.

Speaking of the Win32 version, I believe there is another bug there:

  fd = CreateFile(ln, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS,
                  FILE_ATTRIBUTE_NORMAL | FILE_FLAG_DELETE_ON_CLOSE, NULL);
  free(ln);
  if (fd == INVALID_HANDLE_VALUE) {
    return lfs_win32_pusherror(L);
  }

free() may change the "last error" value of the current thread, and
lfs_win32_pusherror() will then fail to report it properly.

Cheers,
V.