Sandboxing (poll)

[Robin]

Also see SELÖVE.

[Rad3k]

Also see SELÖVE.

Yes, I know about SELÖVE. You make it pretty hard not to know about it In fact, it inspired me to resurrect this thread in the first place

I was more curious about what do you think about the idea I presented (SELÖVE could be one part of the solution). Initial question was whether to sandbox LÖVE or not. Either choice has its advantages and disadvantages, which depend on what you want to use LÖVE for. So, why not have it both ways instead? Some people mentioned possibilities of optional sandboxing, e.g. through a command-line switch, or issuing a warning to the user if a game tried something suspicious. But neither solution appeared to me as elegant and obvious (from the user standpoint) as this one. It was inspired by:

In fact, if I could have LÖVE as a Lua module, i'd be even happier.

If we could have LÖVE as binary Lua module, then the executable would be just the sandbox, virtual filesystem and all the startup automation.
I don't know the interals of LÖVE, and I may have made some incorrect assumptions about it, so - would such approach be possible (or feasible)?

[Robin]

There is a planned feature for SELÖVE which allows games that want to break outside of the sandbox (within acceptable boundaries) to do so if they get permission from the player. Not sure if that is what you were talking about, but there you go.

[slime]

Is SFML sandboxed? LÖVE has nearly identical features as SFML (the main difference being the API is Lua). XNA is also very very similar, but it's (mostly) Microsoft-only and it supports 3D. Is that sandboxed? Why or why not?

My personal opinion: I don't give a shit what version of LÖVE you're using if you run my .love file, as long as it works. My end goal is never ever to give people a .love file, it's to give people an actual working game. If the main branch of LÖVE starts sandboxing stuff for the sake of people who only want to run .love files, then I'll probably move on to something else or delete the code from my own LÖVE build (I'd still post my LÖVE files, it'd be your loss if you can't run them).

[ljdp]

I had a quick skim through this thread so it might have already been mentioned.
I suggest standard read, write, delete functions are allowed but for delete and write a dialogue is show asking

Code: Select all

Are you sure you want to delete -file- from -path-?

Code: Select all

Are you sure you want to write -file- to -path-?

Edit:
I'm also thinking of where a game has an 'addon' system perhaps for extra levels where you would want to disable io functions. But this could be done with standard lua scoping, no?

[Robin]

I suggest standard read, write, delete functions are allowed but for delete and write a dialogue is show asking

Code: Select all

Are you sure you want to delete -file- from -path-?

Code: Select all

Are you sure you want to write -file- to -path-?

Wouldn't that lead to the Vista problem, since they would generally to a lot of those operations over time? (Gamers getting tired of those questions and starting to answer them with "Yes" automatically, making the whole construct completely useless.)

My idea is that a game that wants to be partially de-sandboxed for a certain reason can call a function that prompts the user and then lets the game do what it wants if they reply positive.

[ljdp]

Wouldn't that lead to the Vista problem, since they would generally to a lot of those operations over time? (Gamers getting tired of those questions and starting to answer them with "Yes" automatically, making the whole construct completely useless.)

My idea is that a game that wants to be partially de-sandboxed for a certain reason can call a function that prompts the user and then lets the game do what it wants if they reply positive.

In an OS, yes you access the filesystem all the time, but how often do you write files in a game? If a game had an auto-update feature as was going to write the new version to my desktop I'd like to know it was happening and be given the option to decline, I believe that is good design.

[Robin]

The thing is that if you do it that way, the prompt has to be enforced by LÖVE for every file read/write, or the game can just find a way around it and to all kinds of naughty stuff.

[T-Bone]

Yes. LÖVE is designed for games. Games should do no evil.

[Rad3k]

Yes. LÖVE is designed for games. Games should do no evil.

That's right, but LÖVE is good for other things too. The point I'm constantly trying to make, is that if standard LÖVE distribution consisted of Lua module and a sandboxed executable using it, then:

• Those who make games that don't need the restricted functionality could distribute them as .love files with no problems.
• Reasonable safety of running .love files would be ensured by the sandbox.
• Those who need the restricted functionality could distribute their games or apps as standalone Lua programs, or together with custom LÖVE builds*.
• Running LÖVE games or apps in the form of Lua programs or unrestricted executables wouldn't be any less safe than it always is.

Wouldn't that make all this arguing needless? Isn't that a win-win?

* - unrestricted LÖVE executables could be provided for this purpose in addition to, but outside of the standard distribution.