[Question] Is this library safe?

[alexmozaidze]

I am new to Rust and Lisp and don't know on wether this library has IO or other types of unsafe operations. Appologies if this is a dumb question.

[alexmozaidze]

Closing due to cringe. I was tired and didn't think to look at how the functions are defined in the default_env module

[brundonsmith]

Sorry for just now seeing this!

This crate does not use any unsafe { } blocks or functions (at least internally; I can't speak for its dependencies)

[cedric-h]

the std uses (thoroughly audited) unsafe, and Rust has to talk to potentially unsafe operating systems (read the std's Rust's bindings to C's berkeley sockets some day, it'll blow your mind how much this Rust std code reads like C). Rust's static memory guarantees exist to make the best of a really unsafe situation.

that being said, I don't think that's the kind of safety that alex was talking about. he meant things like file access or the ability to run rm -rf --no-preserve-root / or what have you. basically, can you run untrusted code -- that may, for example, come from random people on the internet -- inside of rust-lisp and trust that it won't break your system. a relevant class of bugs here are buffer overflows that might let you do things like stack smashing. fortunately Rust largely guards against this class of errors, since you aren't using any unsafe. TL:DR; what alex was really asking was, is rust_lisp sandboxed

personally, yeah, I'd probably let random people run short-lived rust_lisp scripts on my server, no harm no foul :)

[brundonsmith]

If that is what they meant, then yeah, it should be reasonably safe. It almost exclusively acts as a delegate to native functions; I'm pretty sure (it's been a year or so since I looked at this) that all I/O happens through Value::NativeFuncs, which you'll largely be writing yourself. You could even pare down the included ones like print if you wanted to, for hardening or whatever other reason. So in terms of protecting the host environment, you should have a lot of control over your attack surface.

I should add, though - while it's not a security issue per se, this crate makes extensive use of Rc<RefCell<>>s. Rcs can cause memory leaks (of particular note: any reference cycles inside your Lisp structures will not get collected), and RefCells can cause a panic (but not an actual memory error), if any of my code is written incorrectly and tries to borrow something when it shouldn't.

Finally, to be frank, I am not currently doing any work on this project and don't have any specific future plans for it, so use at your own risk etc. That said I would probably be willing to fix minor bugs that get reported, and/or review pull-requests, if someone starts using it for something real.

Cheers!