Suggested *nix style for blocks and items

chessandgo

Member
Contributor
Hunter
I propose a *nix style permissions for blocks and items be added to core. I can only paraphrase how it works, as wikipedia will be much better at explaining it. There is an owner of a file, its group, and other groups. they all have various levels or read, write and execute. . This would be beneficial to add to core. Minecraft is a mess with permissions, as there are very few levels of permissions in vanilla (op, user, adventure mode, hardcore mode, creative mode, spectator mod, lesser ops). And the plugins for it are horrible. (not to mention there are multiple ones) So, lets say, have users be in groups with rights etc. Ops would be in the super user/sudo group, they can break anybodies blocks and use any items. This will be the default mode single player. (or root). Now, simple by what groups the blocks/users/items are in we can get some pretty fine control. don't want a player to break something? Making only users in said group be able to break those blocks. Don't want a user to be able to use a tool, make all tools (via a global config, perhaps, or add an argument to ever time said item is spawned/created) have higher permission level/different group. So, execute would be using a block/item, write, which falls under editing, so removing or changing a block. (probably should have more finer control when we implement this), and perhaps reading, she reading make blocks not even render for their client, no transparent, just void. a static, no data sent to client.


So, say a chest is owned by a player and they are the only one in a group/their group. All other groups cant interact with it/

So simple put, you can protect blocks from specific types of users, or people by editing their ownership, group, and other group permissions. Op players can obviously add them selves to groups to destroy said block.


We're gonna need a login system of sorts in order to sort this out/ make it work.


Perhaps player properties should be put under *nix permissions too. Like *nix commands, anyone can execute them, it just might not do anything. (IE, any user can execute update-grub, but nothing will happen because the thing that it acts on has permissions too high for them, thus only super users can do it). IE, anyone can type 'stop', but only ops will do something because there user has sufficient privilege level for the things 'stop' acts upon.

This will solve the 'let certain users fly' problem. add the user to the fly group. only ops can do it because they are the only one who have the necessary rights to the command. anyone can try to add them selves to the fly group, but there lacking privileges will cause it to fail.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
IMHO having thought on this a bit I think there are two distinct topics involved
  1. Server type permissions - ability to do things like kicking and banning users
  2. In-game property type permissions - applied to actual objects in the game world
For #2, which is probably vastly larger in its scope and impact on gameplay I'd like to actually see an elegant in-game solution of group membership, fashioned around collectives like clans, guilds, cities, kingdoms, etc. No artificial groups or server administrative stuff, although behind the scenes it is possible this sort of in-game action could result in something like a server ban. Imagine a king exiling a player for a period of time.

In a very basic world this could be simple enough to not look very different from there being a normal user group and an admin user group. The server owner just spawns some object that creates a group then adds people to it. Areas and objects could then be defined in some in-game fashion. Or via console commands until we have cleaner ways to do it.

#1 should actually shrink over time as fewer and fewer debug commands are needed. Flying via console command shouldn't be needed beyond testing.

I'm not sure the *nix angle here is very relevant as it more or less describes a generic user/group permission system. In many cases that is insufficient, thus systems like SELinux were added in. But we most definitely need a permission system sooner or later :)
 
Top