search

mlua-rs / rlua

High level Lua bindings to Rust
Other
1.72k stars 115 forks source link

Make rlua::Lua constructor unsafe #192

Closed jugglerchris closed 9 months ago

jugglerchris commented 4 years ago

As copied from https://github.com/amethyst/rlua/issues/172#issuecomment-616975763

rlua needs to give up on trying to patch out the UB in PUC-Rio Lua itself, and simply admit this fact by making the Lua constructor unsafe. This is COMPLETELY different than giving up on bindings soundness, I still consider bindings soundness to be extremely important, but this would give up on things like trying to protect rlua usage from things like the debug module or its many other ways to cause UB like directly loading dlls or even just through loading bytecode. Maybe some form of truly sandboxed Lua could be provided as a safe interface, but I don't think it should be advertised as the default because it removes too much of Lua itself.

SoniEx2 commented 3 years ago

You can crash Rust by messing with files in /proc. Should fs be made unsafe because of that?

Making Lua unsafe makes as much sense as making fs unsafe, tbh.

jugglerchris commented 3 years ago

@SoniEx2 It sounds like rlua maybe isn't the crate you want?

SoniEx2 commented 3 years ago

Why's that? It's supposed to be bindings, but it's currently (attempting to be) a sandbox.

jugglerchris commented 3 years ago

While I'm sure they weren't intended that way, the tone of your comments seems (at least to me) to be somewhat aggressive and quite negative. I think trying to use your interpretation of the very brief headline "high level Lua bindings" to say that the project is trying to be something else is not very constructive. (Personally, although there might be a few details that aren't quite right, on the whole the emphasis on safety in rlua is exactly what I wanted - I switched from a different Lua library to this one)

SoniEx2 commented 3 years ago

Ah, right. Sorry.

We've been following rlua since when Rust made longjmp through FFI an abort. It seems rlua is the only bindings that attempt to properly handle that stuff, as well as being (sometimes mis)guided by the same principles we followed when making our hexchat plugin crate (which we should maybe work on finishing at some point).

Yet we can't help but feel like it's trying too hard. Lua is a programming language. We make safe bindings for other programming languages, including unsafe ones like C. Should we say everything that claims to be safe bindings for C libraries is actually unsafe? Because at the end of the day, you can often misuse those libraries and/or they can have security exploits, which would count as unsafe. Including std::fs (e.g. /proc/self/mem). And Lua does not proclaim to be safe, just embeddable.

jugglerchris commented 3 years ago

I think Lua is different in this area to C. In my application I trust a non-expert user (who may be me on an off day) to write Lua to customise my application - Lua is safe enough for that. I want to be confident that they're not going to accidentally corrupt application state by mistake - they might bomb out from a runtime Lua error, but it's not going to cause their e-mail to be deleted.

I would definitely not trust myself to write C safely in the same context - I don't think that's a reasonable comparison.

SoniEx2 commented 3 years ago

Well, yeah. But we'd say doing unsafe things with Lua, outside of accidentally loading malicious source/bytecode, requires deliberate intent, even with the debug library.