FOSS gamedev and creative worlds

I believe this was posted before, but a quick search returned nothing.

What can be done with client side lua ?

1 - Maps of all kinds, ores, caves etc, user added tags, etc..
2 - Clocks and compasses (ore detector etc).
3 - Computer interface (its currently impossible)
4 - Sound streaming from server to client (radio turners, tv sets)
5 - Client side texture modifications and render to texture (cameras, tv sets, mirrors) [Needs irrlich render to texture and texture manipulation API in client side scripts], clients can disable mirrors if wanted.
6 - Ballistic and rocket weapons with low server load.
7 - Vehicles (cars, carts, airplanes) Less lag when driving, sends updates to server, but those updates need not be exact (think about a delta engine), just general positions, while the same movement can be very detailed in client side, like taking physics into account (realistic flight sim, trains that pull cargo wagons etc).
8 - sub-block machines (a machine that is a single block for the server, but is a complex machine at client side) with input and outputs to minetest world. (computers, microcontrollers).
9 - with some engine adjustments, you can render, say, videos to a texture locally (minetest tv set) etc.

Anything that is single player centered and needs only read access to the map, produces client side effects only or can be layered into subcomponents that the server need not know the internal states of (a computer simulated in minetest doesnt need to expose all internal states to the game world, just i/o needs to be exposed, floppies and ram needs to be stored client side etc), things whose level of detail can be coarse in server side but can be fine grained client side (ex.: a radio set that instructs client to download music from a music server to be played locally, minetest server only needs to know music url and name, not the actual ogg vorbis file content, egg).

Client side immersive sound, as well.

aldobr wrote:3 - Computer interface (its currently impossible)

Can you clarify what a "computer interface" is?

aldobr wrote:8 - sub-block machines (a machine that is a single block for the server, but is a complex machine at client side) with input and outputs to minetest world. (computers, microcontrollers).

Why should the client calculate these things instead of the server?
This would prevent multiple people from using such thing at once.

aldobr wrote:9 - with some engine adjustments, you can render, say, videos to a texture locally (minetest tv set) etc.

Client-sie Lua won't have filesystem access, even if you have a video implementing a video decoder in lua is probably not a good idea.

aldobr wrote:floppies and ram needs to be stored client side

This goes against the principle of the server having the map with everything that belong to it. And again multiple players won't be able to use one device at once.

IMHO the game needs to head in this direction eventually, but it would be a pretty significant rewrite to add client side mods and properly deal with messy server synchronization, deployment and security issues. The beauty of the current model is that it lends itself to a simpler and saner (albeit laggier) sandbox for mods. Anyway, it's going to take someone sufficiently motivated to get the ball rolling. It's open source, so it could be you... :P

Can you clarify what a "computer interface" is?

Graphical console with pixel access cant be reasonably implemented in server side.
Even text based console is hard to implement and laggy, besides adds a lot of load to the server without much gain. This can be reasonably implemented client side, even mimmicking vt-100 type terminals.

Why should the client calculate these things instead of the server?
This would prevent multiple people from using such thing at once.

Think about object oriented programming. Classes only export "public" methods, not "private" ones, because those private methods are not need/desirable outside the class implementation.

Same is true for a computer or microcontroller : you cant see whats inside a microcontroller that is controlling a robot in a factory, neither is desirable or needed that you do, you just need to see the input output : the arm is at position X, etc... (who in the server, besides the mod itself, needs to know register A1 value ?, only exception to this is debugging, but being client side it can be debugged locally etc).

This is a kind of modularization and information hidding, with the plus side of being a distributed system where the load is shared across clients whenever possible/makes sense.

Client-sie Lua won't have filesystem access, even if you have a video implementing a video decoder in lua is probably not a good idea.

You wont implement a video decoder in lua but allows lua to access codec dlls/so via a white list of dll/so that can be accessed using luaffi. Frames could be stored in textures in video memory.

We just need a way to give access to the rendering routines to lua code (something that can only be done in client side). Just superimpose arbitrary textures to the cube and it becomes a tv of sorts, or mirror.

Even being client side this wont be 30fps video, but enough to mimmick real world objects.

This goes against the principle of the server having the map with everything that belong to it. And again multiple players won't be able to use one device at once.

If the computer floppies/hard disks are stored in the server, how to send new floppies to the server ?

uploading arbitrary files to the server is a much bigger security risk than storing them locally.

it makes more sense to store them locally and share code via normal filesharing applications outside the scope of minetest client.

aldobr wrote:with the plus side of being a distributed system where the load is shared across clients whenever possible/makes sense.

Minetest is going to get an Android version soon, I don't think it is a good idea to add additional load to phones which already have spare resources available.
(Not only about not being fast enough, but also about battery life)

aldobr wrote:

Client-sie Lua won't have filesystem access, even if you have a video implementing a video decoder in lua is probably not a good idea.

You wont implement a video decoder in lua but allows lua to access codec dlls/so via a white list of dll/so that can be accessed using luaffi.

So if someone finds a vunerability in any of the allowed DLLs you're basically screwed?

aldobr wrote:

This goes against the principle of the server having the map with everything that belong to it. And again multiple players won't be able to use one device at once.

uploading arbitrary files to the server is a [...] security risk.

Can you explain why this is a security risk?

aldobr wrote:it makes more sense to store them locally

I disagree but it still goes against the principle of the server having the map with everything that belongs to it.

Minetest is going to get an Android version soon, I don't think it is a good idea to add additional load to phones which already have spare resources available. (Not only about not being fast enough, but also about battery life)

Think about that way :

You have a task that is pretty simple : draw a game map onscreen based on the current chunk.
You have 30 clients online.
The server draws the map 30x with different chunks and player positions.
If we offload the task to the clients, they will have to draw the map only once.

You are at the shopping center. You finish eating your macfish.
Do you take the garbage to the trashcan or do you leave the garbage at the table to be collected by the janitor ?
Look by the point of view of the customer, collecting his own garbage is easy, because its the garbage of a single person. By the point of view of the janitor it becomes a true job, because he has to collect garbage from thousands of people.

Thats the idea.



Where is harder to find a vulnerability : in ffmpeg library or in minetest ?

You can allways create a stub library that exports only interesting functions and filters parameters and whitelist that library.

Can you explain why this is a security risk?

Every time a server has to do something on behalf of a external client (instead of on behalf of a local user), this is a security risk, because the server usually runs under a uid with much higher powers than an casual user would have if he was directly logged into the OS instead of via a server.

So if you run your minetest server with root user privileges, any bug in the server will allow malicious clients to damage files that are only accessible to the client. This is much more of a security risk than allowing the emulated CPU run on the client side and accessing client resources.

Besides this is just a matter of deciding where we intend of having more risks: client side or server side.

Current minetest implementation is not anywhere near "safe" anyway.

aldobr wrote:

Minetest is going to get an Android version soon, I don't think it is a good idea to add additional load to phones which already have spare resources available. (Not only about not being fast enough, but also about battery life)

Think about that way :

You have a task that is pretty simple : draw a game map onscreen based on the current chunk.
You have 30 clients online.
The server draws the map 30x with different chunks and player positions.
If we offload the task to the clients, they will have to draw the map only once.

Your whole example is invalid because you were talking about computers or microcontrollers before.

aldobr wrote:8 - sub-block machines (a machine that is a single block for the server, but is a complex machine at client side) with input and outputs to minetest world. (computers, microcontrollers).

But still: You're right, it would be impractical to let the server render a map.

aldobr wrote:

So if someone finds a vunerability in any of the allowed DLLs you're basically screwed?

Where is harder to find a vulnerability : in ffmpeg library or in minetest ?

Equally hard.

aldobr wrote:You can allways create a stub library that exports only interesting functions and filters parameters and whitelist that library.

What if that "stub library" has a vunerability?

aldobr wrote:

Can you explain why this is a security risk?

Every time a server has to do something on behalf of a external client (instead of on behalf of a local user), this is a security risk, because the server usually runs under a uid with much higher powers than an casual user would have if he was directly logged into the OS instead of via a server.

Any outward facing services should run with minimal privileges (meaning that they can only use what they need to use).

aldobr wrote:So if you run your minetest server with root user privileges,

If somebody is willing to risk their whole server by running a service with root privileges, there is nothing anyone can do to save that person.

aldobr wrote:any bug in the server will allow malicious clients to damage files that are only accessible to the client. This is much more of a security risk than allowing the emulated CPU run on the client side and accessing client resources.

Reverse argument:
Any bug in the client will allow malicious server to access/damage files that are normally not accessible.

aldobr wrote:Besides this is just a matter of deciding where we intend of having more risks: client side or server side.

Having more risks on the client side is bad because there are way more client than there are servers.

Your whole example is invalid because you were talking about computers or microcontrollers before.

Nope, 1st post is clear. Not only microcontrollers.

Equally hard.

As much as we love minetest and as we are thankfull of its developers hard work, you cant compare a library that maybe have hundreds of developers and thousands of users with a game that has dozens developers and hundreds of users... ffmpeg is safer and is used in a lot of places. Same is true for a lot of other libraries.

Any outward facing services should run with minimal privileges (meaning that they can only use what they need to use).

Non sequiteur, even running with least privileges, do you agree that even the basic privileges of the server are more than a casual player would have in the same server ? even if he cant compromise the server itself (1st rule to hack a server is to gain user privileges in it) he can at least ruin the game and annoy other players...

If somebody is willing to risk their whole server by running a service with root privileges, there is nothing anyone can do to save that person.

Even if not compromised initialy as root, gaining user level access to a system is usually the first step into hacking the server...

Any bug in the client will allow malicious server to access/damage files that are normally not accessible.

lua sandboxing.

Having more risks on the client side is bad because there are way more client than there are servers.

simply disable lua client scripting.

So, I am to believe that no matter what happens, there will never be client lua? I hope I am wrong there.

aldobr wrote:

Equally hard.

[...] fmpeg is safer

[citation needed]

aldobr wrote:and is used in a lot of places.

Not an argument for that.

aldobr wrote:

Any outward facing services should run with minimal privileges (meaning that they can only use what they need to use).

[...] he can at least ruin the game and annoy other players...

This should be solved by the mod itself and not Minetest itself.

aldobr wrote:

If somebody is willing to risk their whole server by running a service with root privileges, there is nothing anyone can do to save that person.

Even if not compromised initialy as root, gaining user level access to a system is usually the first step into hacking the server...

I did not say not running the server as root is the only thing that can be done.

aldobr wrote:

Any bug in the client will allow malicious server to access/damage files that are normally not accessible.

lua sandboxing.

Sandboxing is hard, what if there is a bug in the sandbox?

aldobr wrote:

Having more risks on the client side is bad because there are way more client than there are servers.

simply disable lua client scripting.

So yo want no client side lua at all?

citation needed

Not an argument for that.

Of course it is. The sheer number of eyes looking at ffmpeg source code and the much bigger profile of that library makes it way safer than minetest.

Why there are more viruses for windows ?

Simply because windows has way more users plus its a closed source software, wich means that there are less eyes looking at its source code.

Thats common sense.

This should be solved by the mod itself and not Minetest itself.

Nope, you are using wrong arguments here.

First you object client side lua scripting on the grounds that the user cannot tell if a mod is malicious or not.

Then you say that mod creators should solve that safety problem ?

Client side lua is unsafe, not only because of badly designed or malware mods, but because of the inherent unsafeness of running arbitrary code into a machine. Well, this is true on both sides, either client or server side.

You might say that arbitrary code is less safe on client side than on server side. You ignore that in a client server model both sides can compromise each other (IE.: a server side malware mod CAN compromise client machine and vice versa).

Sandboxing is hard, what if there is a bug in the sandbox?

Dual standards. On server side you accept a lot of compromises - like current lua server side allowing arbitrary fopen calls - while on client side you expect total absolute security. As is common knowledge that absolute safeness is impossible, this is tantamount to preemptively ruling out client side scripting. Following that reasoning current browsers would be totally static, their scripting subsystems being unable to be made totally safe (because that goes against fundamental aspects of computer science) ruling out client side scripting.

So yo want no client side lua at all?

No, i want client side scripting with the possibility of it being disabled by the user, just as all browsers (i believe) allow javascript being disabled for more safety but less functionality.

I don't see how downloading and installing client side mods is any less dangerous than downloading and installing mods for singleplayer. As for the server hacking risks, a developer good enough to hack a server with the client lua api would be good enough to hack the server by editing the c(++) code.

Hacking: malicious damage, taking down, griefing, etc.

The security issue is that if not implemented carefully client side lua will make it possible to send arbitrary lua code to the client without the client even knowing about it. But allowing the server to send code (or at least a download link) to clients is what's needed to reduce the pain of making sure all clients are using the "right" version of a mod. That's quite a different issue from knowingly downloading a client side mod. This is not to say it shouldn't be done, but it is naive to pretend there won't be extra security risks.

Its naive to pretend that the security risks preclude the inclusion of client side lua.

That mode of thinking would not given us Web 2.0, for example.

Its just a cheap way to dismiss something that the developers dont want happening.

The old wiki said about client-side modding, back when the modding API was just added (December 2011):

Please do not bitch about client-side modding: the open source nature of Minetest has gone nowhere. [stuff about patches being welcome goes here, I don't remember it]

Client side modding will have to be done sooner or later.
Without it we wont have smooth animations, mobs etc.
Putting everything at servers head is a road to nowhere.

Security should always be taken seriously. Fortunately, Lua was built for this sort of thing, and truly is REALLY easy to sandbox. The standard library API listing fits on one page. And you can completely wipe it clean and whitelist the API calls you know are safe from the ground up, optionally replacing some of the rest (e.g. io.open) with a few carefully wrapped alternatives. For goodness' sake, you can't even read the contents of a directory without third-party libraries!

I'm actually a little tired of carefully grepping through and inspecting every mod I want to try out, so I've even been thinking of ways to sandbox the Lua environment for server-side mods too. For example, io.open could be replaced with something that absolutely forbids reading outside the ~/.minetest directory tree (unless the user is foolish enough to add bad symlinks in there or something).

sfan5 wrote:This goes against the principle of the server having the map with everything that belong to it.

I have to agree, that this should always remain the case. Client side activity should be limited as much as possible to graphics. Allowing mods for this would be a good idea, and as I see it would probably include a lot of the stuff listed in OP? Basically everything but #8 and #3 which to me sound like essentially the same, and like things that should definitely be left server side (or not done at all).

#3 must be client side. Drawing a computer interface from server side is inefficient. This is just the interface (GUI or Text) not the computer logic.