Players executing `/list_areas` without the `areas` priv cause minetest-5.7.0 and multicraft-2.0.0 to lock up hard.

[dennisjenkins75]

Server: EdenLost, running multicraft-2.0.0 will lock up hard (with 100% CPU usage for the server thread) if a regular player (ex: "1hit") issues /list_areas. The same command does not lockup when a full admin ("sysadmin") runs it (a huge list of areas is returned though, for every player).

1hit@EdgyNet:~$ sqlite3 -column ./worlds/world/auth.sqlite \
  "select a.name, up.privilege from auth a, user_privileges up \
    where (a.id = up.id) and (a.name in ('1hit', 'sysadmin')) and (up.privilege like '%area%');"
1hit      area_high_limit 
1hit      area_protect    
1hit      areas_high_limit
1hit      areas_protect   
sysadmin  areas           
sysadmin  areas_high_limit
sysadmin  pvp_areas_admin 

I granted areas priv to 1hit and retried /list_areas as 1hit, and the server no longer locked up.

I don't know why 1hit has seemingly duplicate privs of area_high_limit, area_protect vs areas_high_limit. I'll audit privs offline soon. Maybe the priv name changed, or maybe I screwed something up earlier. Players other than 1hit can lock up the server by issuing /list_areas and they only have the areas_protect priv and none of the others.

So it seems that anyone lacking areas, who issues /list_areas on multitest-2.0.0 with the latest version of this areas mod can lock up the server. I do not think that this is the same as issue #51.

[dennisjenkins75]

This also causes minetest-5.7.0 to lockup as well.

[fluxionary]

i can run the command just fine locally with 5.8 and on the your-land server, which runs 5.7, and where i have a sizable number of areas, as an unprivileged player.