Re: Suggestion: Lua 5.3 -- a facility for creating and manipulting Lua file handles (C API)

[Coda Highland <chighland@...>]

Oh, sure, if we're talking security we've got a completely different
can of worms to deal with. If you're exposing scripting to untrusted
users, then of course you need to address things differently than if
the scripting is internal to the program and you can trust the
developer.

But if you're talking about opening up low-level file access to the
API, well, it's pretty clear you're not looking at security.

/s/ Adam

On Fri, Nov 15, 2013 at 2:40 PM, Sir Pogsalot <sir.pogsalot@gmail.com> wrote:
> I have a friend who does security that would *love* you :p
>
>
> On Fri, Nov 15, 2013 at 8:49 PM, Coda Highland <chighland@gmail.com> wrote:
>>
>> Ah, see, we've got completely opposite views there. If the user *has*
>> screwed with the io library, then I WANT to support the changes
>> they've made! They've surely got a good reason for it, and if you want
>> Lua to manage your file handles instead of managing them opaquely,
>> then trust the user (who isn't an end user -- the user of your library
>> is a developer and therefore (probably) isn't a complete numbskull
>> when it comes to making engineering decisions).
>>
>> /s/ Adam
>>
>> On Fri, Nov 15, 2013 at 12:45 PM, Sir Pogsalot <sir.pogsalot@gmail.com>
>> wrote:
>> > That is what I initially tried for -- I had a function called something
>> > like
>> > `void push_ref_to(luaL_State *, char *)'  that I would call like
>> > push_ref_to("io.close") and it would leave the function on the stack.
>> > The
>> > problem was I got paranoid thinking about dumb end-users messing up the
>> > io
>> > table -- then require()'ing in my project and my code hoping that
>> > io.close
>> > was still where it ought to be.
>> >
>> > I tend to avoid relying on where things should be on the Lua side unless
>> > I'm
>> > starting the interpreter and setting up the env before the user gets to
>> > it
>> > -- otherwise I can't sleep at night :(
>> >
>> >
>> > On Fri, Nov 15, 2013 at 8:18 PM, Coda Highland <chighland@gmail.com>
>> > wrote:
>> >>
>> >> If you need to share file objects between C code and Lua code I for
>> >> one would consider just grabbing open() from the global scope and
>> >> invoking that using lua_pcall. This would guarantee that both sides
>> >> have equivalent behavior as well as allowing Lua code to monkey-patch
>> >> open() to expand on the functionality (e.g. for an embedded resource
>> >> system that's transparent to application code).
>> >>
>> >> /s/ Adam
>> >>
>> >> On Fri, Nov 15, 2013 at 12:08 PM, Sir Pogsalot <sir.pogsalot@gmail.com>
>> >> wrote:
>> >> > Hmm, alright -- "it's by design".  I copied out newfile() and
>> >> > io_closef() in
>> >> > my own project I wanted to be sure that I would not invite potential
>> >> > problems by rolling my own.
>> >> >
>> >> > https://github.com/Pogs/lsock/blob/master/lsock.c#L800
>> >> >
>> >> > Not sure what I meant by manipulating file handle objects really,
>> >> > it's
>> >> > just
>> >> > important to be able to create files and close them.  Because
>> >> > luaL_Stream/LStream wasn't in the manual and I had to go digging into
>> >> > the
>> >> > source it felt like something that was intended to not be used.
>> >> >
>> >> > My point is that it might be nice to have these function to make sure
>> >> > that
>> >> > everyone creates their file handle userdatas in the same way (maybe
>> >> > it
>> >> > belongs it would go in the auxiliary lib?):
>> >> >
>> >> > void * luaL_newfile(lua_State *);
>> >> > void luaL_closefile(lua_State *);
>> >> >
>> >> > extra?
>> >> > FILE * luaL_getFILE(void *);
>> >> > void luaL_setFILE(void *);
>> >> >
>> >> > You're telling me I should perform those 4 steps (create the
>> >> > userdata,
>> >> > set
>> >> > the metatable, assign the stream to f, roll my own closef() and
>> >> > assign
>> >> > it)
>> >> > -- I'm saying this basic procedure will be done improperly by someone
>> >> > and
>> >> > we'll have the same issue.  Instead of people rolling their own
>> >> > different
>> >> > file handle type we'll have the same userdata but improperly
>> >> > "formed".
>> >> > :>
>> >> >
>> >> > newfile() should take care of assigning the internal io_fclose()
>> >> > function
>> >> > address, closefile() would be for closing the file without the user
>> >> > knowing
>> >> > how luaL_Stream is defined.  getFile()/setFile() are just extras --
>> >> > unnecessary of the LStream structure were documented in the manual...
>> >> >
>> >> > I obsess too much, I think :\  Bad ideas?
>> >> >
>> >> >
>> >> > On Fri, Nov 15, 2013 at 4:31 PM, Roberto Ierusalimschy
>> >> > <roberto@inf.puc-rio.br> wrote:
>> >> >>
>> >> >> > LUA_FILEHANDLE is a preprocessor definition in lauxlib.h, which is
>> >> >> > just
>> >> >> > "FILE*"
>> >> >> >
>> >> >> > So what this means is luaL_checkudata() gets the metatable of the
>> >> >> > userdata
>> >> >> > object (if it has one), and checks to see that it matches the
>> >> >> > table
>> >> >> > referenced by the key "FILE*" in the registry table.
>> >> >> >
>> >> >> > Lua file handles themselves are called luaL_Stream's or just
>> >> >> > LStream's
>> >> >> > (there's a typedef in liolib.c[2]).
>> >> >> >
>> >> >> > typedef struct luaL_Stream {
>> >> >> >   FILE *f;  /* stream (NULL for incompletely created streams) */
>> >> >> >   lua_CFunction closef;  /* to close stream (NULL for closed
>> >> >> > streams)
>> >> >> > */
>> >> >> > } luaL_Stream;
>> >> >> >
>> >> >> > ^ found in lauxlib.h[3]
>> >> >> >
>> >> >> > Lua file handles, in their C form are just ANSI C FILE *'s and a
>> >> >> > pointer
>> >> >> > to
>> >> >> > the function to close them (io_fclose() in liolib.c[4]).
>> >> >> >
>> >> >> > To create a Lua file handle you would need to call newfile() in
>> >> >> > liolib.c[5], but this function is static and therefore not
>> >> >> > exposed.
>> >> >>
>> >> >> You do not need to call newfile. Lua exports everything you need to
>> >> >> create
>> >> >> your own files. All you have to do is this:
>> >> >>
>> >> >> - call lua_newuserdata(L, sizeof(LStream)) to create a userdata
>> >> >> - set its metatable with luaL_setmetatable(L, LUA_FILEHANDLE)
>> >> >> - set its 'f' to your stream
>> >> >> - set its 'closef' to the function that will close your stream
>> >> >>
>> >> >> Everything here (lua_newuserdata, LStream, luaL_setmetatable,
>> >> >> and LUA_FILEHANDLE) is public on purpose. Because LUA_FILEHANDLE and
>> >> >> LStream are public, you can also write your own functions to
>> >> >> manipulate
>> >> >> files (and they will work with native Lua files too).
>> >> >>
>> >> >> -- Roberto
>> >> >>
>> >> >>
>> >> >
>> >>
>> >
>>
>