Unsafe functions

[Disinterpreter]

Describe the solution you'd like

From: #1937 (comment) #1782 we decided to allow unsafe functions only with ACL rights.

I'd like to start implementing new functions from ACL fixes.

In the first step we deny all unsafe functions
When we will be sure that these functions blocked by default, we can start to implement ones.

I suppose we should mode current os.* functions under ACL too.

Additional context

Put something like this in Default (check me with methods like "file:close")

<right name="function.require" access="false"></right>
<right name="function.dofile" access="false"></right>
<right name="function.loadfile" access="false"></right>
<right name="function.loadstring" access="false"></right>

<right name="function.os.execute" access="false"></right>
<right name="function.os.exit" access="false"></right>
<right name="function.os.getenv" access="false"></right>
<right name="function.os.remove" access="false"></right>
<right name="function.os.rename" access="false"></right>
<right name="function.os.setlocale" access="false"></right>
<right name="function.os.tmpname" access="false"></right>

<right name="function.io.close" access="false"></right>
<right name="function.io.flush" access="false"></right>
<right name="function.io.input" access="false"></right>
<right name="function.io.lines" access="false"></right>
<right name="function.io.open" access="false"></right>
<right name="function.io.output" access="false"></right>
<right name="function.io.popen" access="false"></right>
<right name="function.io.read" access="false"></right>
<right name="function.io.stderr" access="false"></right>
<right name="function.io.stdin" access="false"></right>
<right name="function.io.stdout" access="false"></right>
<right name="function.io.tmpfile" access="false"></right>
<right name="function.io.type" access="false"></right>
<right name="function.io.write" access="false"></right>
<right name="function.file:close" access="false"></right>
<right name="function.file:flush" access="false"></right>
<right name="function.file:lines" access="false"></right>
<right name="function.file:read" access="false"></right>
<right name="function.file:seek" access="false"></right>
<right name="function.file:setvbuf" access="false"></right>
<right name="function.file:write" access="false"></right>


<right name="function.package.cpath" access="false"></right>
<right name="function.package.loaded" access="false"></right>
<right name="function.package.loaders" access="false"></right>
<right name="function.package.loadlib" access="false"></right>
<right name="function.package.path" access="false"></right>
<right name="function.package.preload" access="false"></right>
<right name="function.package.seeall" access="false"></right>

[xLuxy]

Lots of functions are already disabled by default - see

mtasa-blue/Client/mods/deathmatch/logic/lua/CLuaMain.cpp

Line 75 in a0410c6

void CLuaMain::InitSecurity()

The following functions are safe to use

OS

• os.clock
• os.date
• os.time
• os.difftime

(See:

mtasa-blue/vendor/lua/src/loslib.c

Line 220 in a0410c6

static const luaL_Reg syslib[] = {

)

[xLive]

There's no reason to disable time functions by default

[Disinterpreter]

Lots of functions are already disabled by default - see

mtasa-blue/Client/mods/deathmatch/logic/lua/CLuaMain.cpp

Line 75 in a0410c6

void CLuaMain::InitSecurity()

Yes, I know. But our conflict was started from agreement about unsafe functions must be restricted by default in ACL. It's more agreement problem than technical.

[Disinterpreter]

There's no reason to disable time functions by default

Thanks, I fixed this.

[LosFaul]

I personally would prefer to have unsafe functions loaded via meta.xml,
which would make it far easier to enable it per resource instead of having painfull ACL management.

Besides that ACL would also reduce the performance
and usage of unsafe functions on server side would be advanced topic anyway.

[patrikjuvonen]

I personally would prefer to have unsafe functions loaded via meta.xml,
which would make it far easier to enable it per resource instead of having painfull ACL management.

Besides that ACL would also reduce the performance
and usage of unsafe functions on server side would be advanced topic anyway.

meta.xml based ACL is bad because it doesn't prevent anything (malicious resources, etc.)

[LosFaul]

meta.xml based ACL is bad because it doesn't prevent anything (malicious resources, etc.)

the functions are already unsafe
and if someone doesn't check meta before executing a random resource
then the person is simply not very smart

[patrikjuvonen]

the functions are already unsafe
and if someone doesn't check meta before executing a random resource
then the person is simply not very smart

Unfortunately the majority of our playerbase runs unsafe resources. Just because you believe you can do better, doesn't mean they can. ACL has a purpose, which is why it's there.

[xLive]

The following functions are safe to use

OS

• os.clock
• os.date
• os.difftime

I think you forget os.time?

[LosFaul]

Unfortunately the majority of our playerbase runs unsafe resources. Just because you believe you can do better, doesn't mean they can. ACL has a purpose, which is why it's there.

with that logic you could also disallow c++ server modules entirely...

[Disinterpreter]

with that logic you could also disallow c++ server modules entirely...

You're totally right lol! But I think it might be in ACL because it is a simpler to implementation way.

Existing modules sdk and blocking dofile/require/os.* is absurdly.

[patrikjuvonen]

with that logic you could also disallow c++ server modules entirely...

Let's not go off-topic with "what's worse".

I'm not going to argue further about the benefits of ACL because it's already implemented in MTA for the sole reason of protecting the server. Resources request rights, and the server grants them. Simple as that.

As discussed here: #1782 and #680, ACL is the way to go.

[xLuxy]

Thank you @xLive i might've overseen it :P

[Disinterpreter]

Blocked by #1983