• Es freut uns dass du in unser Minecraft Forum gefunden hast. Hier kannst du mit über 130.000 Minecraft Fans über Minecraft diskutieren, Fragen stellen und anderen helfen. In diesem Minecraft Forum kannst du auch nach Teammitgliedern, Administratoren, Moderatoren , Supporter oder Sponsoren suchen. Gerne kannst du im Offtopic Bereich unseres Minecraft Forums auch über nicht Minecraft spezifische Themen reden. Wir hoffen dir gefällt es in unserem Minecraft Forum!

[PEX] Wie man Permissions sicher einrichtet - für paranoide Anfänger

SilberRegen

Workaholic
Mitglied seit
23 März 2012
Beiträge
890
Alter
28
Minecraft
SilberRegen
HINWEIS: Pex ist veraltet und die offizielle Version nicht mehr sicher.
Server die Pex benutzen können zum Absturz gebracht werden.


Meine Empfehlung: Luckperms

=====================================================================

Ziel:
Erstellung einer "Hacker"-sicheren permissions.yml, mit Einblick in die Überlegungen, die in die Konstruktion eines erweiterbaren, übersichtlichen Rechtesystems gehen.

Schwierigkeit: ➊➋➂➃➄ | Zeitfaktor: ~ 1½ Std.
Andere Tutorials: Alte permissions.yml aufräumen|Neue Gruppen hinzufügen


Voraussetzungen:
  • Zugriff auf die Konsole eures Servers (Sprich: Ihr seid der Administrator/Betreiber/Owner)
  • Kenntnis über die Benutzung dieser Konsole
  • Craftbukkit/Spigot/Paperspigot sind installiert und laufen
  • Kenntnis über die Installation von Plugins
  • Dokumentation aller einzurichtenden Plugins liegt bereit (Die Seite(n), die die Befehle und Permissions auflistet)
Oder zumindest, dass ihr das irgendwo in Erfahrung bringen könnt.
Ein Tutorial zur Installation wurde vor einiger Zeit hier im Forum hinterlassen (Klick mich!). Solltet Ihr dies benötigen, geht bis Schritt 3 vor und kehrt hierher zurück.
[JUSTIFY]In diesem Tutorial wird das Plugin "Modifyworld" benutzt, welches leider seit 2013 nicht mehr upgedatet wird und seit Spigot 1.12 nur noch "halb" funktioniert. Dennoch hat es einige funktionierende Funktionen die ich sonst nur mit mehreren Plugins, die für den Zweck dieses Tutorials zu kompliziert sind (aka zuviele andere Funktionen), oder nicht über Permissions rekonstruieren kann. Für das, was ich in diesem Tutorial damit mache, geht es noch. So gerade eben.

Sollte sich jemand erbarmen und das arme Plugin mal updaten oder mir eine äquivalente Alternative zeigen können, wäre ich mehr als glücklich diesen Teil zu updaten.
Edit: Okay, ich glaube ich habe es selbst gefixt. Scheint alles zu funktionieren, gebe keine Garantie, dass ich nichts anderes kaputt gemacht habe.
Wer die Version möchte, die ich jetzt benutze: https://github.com/SilberRegen/Modifyworld/releases/tag/sil.Ver-1.0.5[/JUSTIFY]
____________________________________________________________________________________________________

Unser Szenario:

  • Spigotserver, Version 1.12.1
  • Modus: Survival, keine Commandblocks
  • 3 Welten: world, world_nether, world_the_end
  • 2 Plugins: PermissionsEx, Modifyworld
  • 3 Gruppen: Gast, Spieler, Administrator
  • ohne Whitelist
  • ohne mySQL-Datenbank (Permissions werden als Flatfile gespeichert)
Wer soll was können?
Unsere Gastgruppe soll sich den Server ansehen dürfen, aber keinerlei Rechte zum Verändern der Spielwelt bekommen. Nutzer müssen zum Spielen "gewhitelistet" aka freigeschaltet werden und damit Teil der Gruppe "Spieler" werden.
Sie Spielergruppe soll alle Rechte zum Verändern der Spielwelt erhalten und einige ausgewählte Minecraftbefehle.
Die Administratorgruppe bekommt dieselben Rechte wie "Spieler" und die Entscheidungsgewalt über die "Whitelist" bzw. das Freischalten.
Zusätzlich soll die Gruppe "Administrator" Rechte für einige der "Operator"-Befehle haben.​

In dieser Zusammenstellung könnten wir uns eigentlich Plugins komplett sparen, wenn wir eine Whitelist aktivieren und den Administratoren OP-Rechte geben.
Der Zweck unseres Tutorials ist es allerdings nicht zu lernen, einen Server möglichst einfach laufen zu lassen, sondern Anhand eines möglichst einfachen Servers zu lernen zielgerichtet Permissions zu vergeben.
Und unser Ziel ist es diese Permissions so zu gestalten, dass sie möglichst sicher gegen Missbrauch und Angriffe sind. Einfach Operatorrechte (OP) zu vergeben, würde genau das Gegenteil bewirken.
Außerdem hätten wir gerne einen Server ohne Whitelist, so dass jederzeit neue Spieler aufschlagen können.

Die permissions.yml die wir uns in diesem Tutorial erarbeiten, habe ich versucht so zu gestalten, dass sie relativ einfach um neue Gruppen, Rangleitern, Welten und Plugins erweiterbar ist. Sollte mich in Zukunft der Drang überfallen noch eines zu schreiben, werde ich auf dieser Datei aufbauen.
Bevor wir uns mit den Permissions beschäftigen eine kurze Auflistung der Dinge, die wir nicht machen.

Sicherheitslücken, die man vermeiden kann:
  • sich OP geben
  • Permissions wie "*" oder "permissions.*" vergeben
  • Freunden OP geben
  • Fremden OP geben
  • Freunden Rechte geben, von denen man nicht weiß was sie machen
  • Fremden Rechte geben, von denen man nicht weiß was sie machen
  • Rechte vergeben, von denen man nicht weiß was sie machen
  • Freunden Zugang zur Konsole geben
  • Fremden Zugang zur Konsole geben
Warum?
Alle Rechte die ihr auf eurem Server habt, können gegen Euch verwendet werden. Dies kam in der Vergangenheit mehr als genug vor und kann jederzeit wieder vorkommen.
Auf einigen Versionen war/ist es möglich, mit einem passendem Client, ein Buch/Schild zu erstellen, dass einen als Link getarnten Befehl enthielt. Zum Beispiel "/op HäCkS0rXDHD" oder "/pex user HäCkS0rXDHD add *" oder gleich beides. Unser Freund "HäCkS0rXDHD" musste dieses Buch jetzt nur noch jemandem zum Draufklicken unterschieben, der die Rechte für diese Befehle hatte.
Auch der Sessionstealtrick ging einige Zeit um. Ohne hier ins Detail gehen zu wollen, wie das Ganze ablief (dazu gibt es einige Threads), funktioniert auch hier der Trick nur mit einem Administrator als Opfer, der die Rechte hatte, Rechte zu vergeben.

In unserem Tutorial ziehen wir gleich die Wurzel des Übels und vergeben an nichts und niemanden Rechte zum Rechtevergeben. Wir haben schließlich eine Konsole und richten alle unsere Permissions ein, sobald wir ein neues Plugin installieren.

Auch dazu noch einige Hinweise, bevor es ans eingemachte geht.
  • Befehle benutzen, statt die Datei zu bearbeiten -> keine Formatierungsfehler
  • Nutzt Copy&Paste für die Permissions -> keine Tippfehler
  • Befehle über die Console ausführen statt Ingame -> Mehr lesbare Zeilen als im Chat, keine unnötige Permissionvergabe
  • Arbeitet auf einem lokalem Testserver -> keine Uploadzeit, schnellerer Neustart
  • Solltet ihr die Datei direkt bearbeitet haben, kontrolliert sie doppelt auf Zeichensetzungsfehler
  • Macht euch eine Übersicht, wer was können soll
  • Arbeitet die Plugins nacheinander ab
  • Überprüft zeitnah die Funktionalität der vergebenen Permissions (mit allen Gruppen)
  • Um Gottes Willen, arbeitet nicht an den Permissions, während der Server öffentlich zugänglich ist
____________________________________________________________________________________________________

Kommen wir nun zu PermissionsEX und Permissions:
(Dokumentation PermissionsEX: https://github.com/PEXPlugins/PermissionsEx/wiki/Commands)

Ein "Permissionnode", kurz "Node" ist die Einheit, um die sich beim Permissionsplugin alles dreht.
So würde der Node "bukkit.command.version" die Erlaubnis an einen Spieler oder an eine Gruppe vergeben, "/version" zu benutzen.
Möchte man nicht, dass ein Spieler/eine Gruppe das kann, vergibt man diesen Node nicht.​

Gemeinerweise geben einige Plugins und auch Bukkit selbst Permissionnodes vor, die jeder "hat" ohne sie zu haben. Herauszufinden, ob dies der Fall ist bei unseren Plugins, welche Nodes betroffen sind und was sie machen, ist sehr wichtig.
So finden wir auf der Bukkitwiki schnell heraus, dass unser Beispielnode genau so einer ist und selbst wenn wir ihn nicht vergeben jeder "/version" benutzen kann.
Wollten wir dies aus irgendwelche Gründen nicht, müssen wir daher den Node in negierter Form vergeben. Bei PermissionEx geht dies durch ein vorangestelltes "-". Dadurch sieht der Node dann so aus: "-bukkit.command.version".

Permissionnodes können an einzelne Spieler oder Gruppen vergeben werden. Da die Anzahl der Spieler schnell wachsen kann und man schnell vergisst, wem man wann was gegeben hat, ist es aber sinnvoll, nur Gruppenpermissions zu vergeben und Spieler diesen Gruppen zuzuordnen.
Dabei müssen nicht alle Gruppen nach außen sichtbar gekennzeichnet sein oder etwas mit der eingerichteten Rangleiter zu tun haben, da Spieler mehreren Gruppen zugeordnet werden können. Der Punkt ist, dass sich die Anzahl der Gruppen nicht unwillkürlich ändert und damit einfach abgefragt werden kann, wer zu einer Gruppe gehört und welche Permissions dort vergeben sind.

"Unsichtbare Gruppen" behalten wir uns aber für ein andern Mal vor und legen zunächst unsere drei Szenariogruppen an.

So schaut unsere frische permissions.yml aus.
Code:
groups:
  default:
    options:
      default: true
    permissions:
    - modifyworld.*
schema-version: 1
Eine Default-Gruppe gibt es bereits in der alle Leute landen, die neu auf unseren Server kommen (default: true). Als Standardeinstellung hat diese Gruppe auch schon den Node "modifyworld.*".
Dies werden wir später ändern, wir belassen aber die Gruppe vorerst so wie sie ist und nutzen sie für unsere "Gastgruppe".

Unser Beispielserver hat kein Chatplugin, dass die Gruppennamen anzeigen könnte. Der Anzeigename kann aber später jederzeit über das Setzen eines Präfix oder "prefix", wie es bei PEX heißt, geändert werden.
Daher ist es egal wie die Gruppen in der Datei heißen. Weil wir sie später in Befehlen benutzen, sind aber kurze Namen ohne Sonderzeichen und Großbuchstaben zu bevorzugen.

Ich habe mich für "spieler" und "admin" als Gruppenbezeichnungen entschieden und lege sie nun an.
Einen Präfix setze ich zu Anschauungszwecken auch gleich dazu und die Permission von "default" entferne ich ebenfalls.

In der Konsole gebt ihr dazu folgendes ein. Jede Zeile ist ein neuer Befehl.
Code:
pex group spieler create
pex group admin create

pex group default prefix "Gast"
pex group spieler prefix "Spieler"
pex group admin prefix "Administrator"

pex group default remove modifyworld.*
Bevor wir jetzt alle Permissions für jede Gruppe verteilen, überlegen wir uns kurz noch, dass wohl die Gruppe "admin" auch die Rechte der Gruppe "spieler" haben soll.
Entweder vergeben wir also die Permission an beide, geben Spielern zwei Gruppen oder wir lassen "admin" einfach die Rechte von "spieler" erben.
Letzteres klingt nach weniger Arbeit, also machen wir das.
Für unser Beispiel hat es keinen Mehrwert, aber für spätere Erweiterungen lassen wir auch "spieler" von "default" erben.
Damit erbt auch "admin" automatisch von "default".
Code:
pex group admin parents set spieler
pex group spieler parents set default
Zur Vererbung merken wir uns, dass vererbte Rechte von gruppeneigenen Rechten überschrieben werden und Einzelrechte von Spielern wiederum Gruppenrechte überschreiben.
Wenn eine Gruppe von mehreren Gruppen erbt, kann dies wiederum durch "weight" beeinflusst werden, darauf gehe ich hier aber nicht näher ein.
Weiterhin können unsere Rechte auch weltenweise vergeben werden, Spieler können in verschiedenen Welten in verschiedenen Gruppen sein und Welten selbst können Rechteverteilungen voneinander erben.

Wo wir gerade bei den Gruppeneinstellungen sind, kümmern wir uns um die Rangleiter:
Später möchten wir gerne mit einem kurzen Befehl unsere neuen Spieler von "default" auf "spieler" setzen können.
Was wir NICHT möchten, ist das jemand "aus Versehen" in der Gruppe "admin" landet.

Daher legen wir an dieser Stelle auch schon die "default"-Rangleiter fest (bei PEX "ladder" genannt). Optional können wir die beiden Gruppen auch auf eine benannte "ladder" setzen, müssen dann aber die "ladder" später im Befehl ausschreiben.
default spieler admin
Code:
pex group default rank 900
pex group spieler rank 800
Damit können wir später "/pex promote <spielername>" um jemanden von "default" auf "spieler" zu setzen.
Die genauen Zahlen sind ebenfalls egal. Wichtig ist nur, dass eine höhere Zahl einen niedrigeren Rang bedeutet.

Der Gruppe "admin" sollten wir auf keinen Fall einen Rang auf der default-Leiter zuweisen.
Im Falle, dass die schon geschehen ist, setzen wir den Rang auf 0 und nehmen ihn damit von der Leiter oder wir entfernen die Zeilen aus der Config. (CAVE: Siehe Bearbeitungstipps)
"admin" soll nur über die Console vergeben werden können. Da dies nur sehr wenige Spieler betrifft, bereitet dies auch nicht allzu viele Umstände.
Die Erstellung von dedizierten "Teamrängen", die ingame vergeben werden können, sei Thema eines anderen Tutorials.


Jetzt kümmern wir uns aber um die Rechte zur Rechteverteilung, für die ich entschieden habe, dass sie global für den ganzen Server gelten sollen.

Unser permissions.yml schaut im Moment so aus:
Code:
groups:
  default:
    options:
      default: true
      rank: '900'
      prefix: Gast
    permissions: []
  spieler:
    inheritance:
    - default
    options:
      rank: '800'
      prefix: Spieler
  admin:
    inheritance:
    - spieler
    options:
      prefix: Administrator
schema-version: 1
Wir haben weiter oben schon geklärt, warum Rechte nur via Console vergeben werden sollten. Daher braucht keine unserer drei Gruppen Rechte dafür.
Unsere "admin"-Gruppe soll "/pex promote" können, daher geben wir ihr dieses Recht und das Recht alle Gruppen außer "admin" Ingame zu setzen. Letzteres wiederum, weil wir paranoid sind und damit weiter absichern, dass keiner aus Versehen an diese Rechte kommt.

Da PermissionsEx dem Befehl "pex user <user> group list", der alle Gruppen eines bestimmten Spielers listet, keinen eigenen Node zugewiesen hat, aber ich den für "admin" gern zur Verfügung hätte, nutze ich an dieser Stelle eine Permission mit *, nur um danach gleich einen Teil davon zu negieren.
Alternativ kann man alle Gruppen, die verwaltet werden sollen jeweils einzeln als Node eintragen, was sinnvoll sein kann, wenn man zum Beispiel um eine Moderatorgruppe erweitert, die sowas können soll. Da ich allerdings davon ausgehe, dass der Administrator alle Gruppen vergeben können soll (außer der eigenen), auch vielleicht welche, die später hinzukommen, mache ich das hier nicht.

Außerdem schalten wir uns noch die Vergabe von "prefix" und "suffix" für Gruppen und Spieler frei, sowie die Hilfe von Pex und die Möglichkeit alle Gruppen aufzulisten. Wer mag kann auch den Befehl zum Auflisten aller User freischalten, da der bei vielen Usern aber gern mal Laggs verursacht und gerne mal ungewollt abgeschickt wird (/pex user), habe ich ihn rausgelassen.
Die Möglichkeit PermissionsEx neu zu laden (permissions.manage.reload), kann ab und an nützlich sein. Tritt dabei allerdings ein Fehler auf, wird dieser nur in der Konsole komplett ausgegeben (Zum Beispiel, wenn in der Datei direkt editiert und ein Zeichenfehler übersehen wurde).
Code:
pex group admin add permissions.user.promote.default
pex group admin add permissions.user.demote.default

pex group admin add permissions.manage.membership.*
pex group admin add -permissions.manage.membership.admin

pex group admin add permissions.reload
pex group admin add permissions.manage
pex group admin add permissions.manage.groups.list
pex group admin add permissions.manage.users.prefix.*
pex group admin add permissions.manage.users.suffix.*
pex group admin add permissions.manage.groups.prefix.*
pex group admin add permissions.manage.groups.prefix.*
HALT! Wir können uns ein wenig Schreibarbeit sparen, weil PEX uns die Möglichkeit ähnliche Nodes zusammenzufassen.
Besonders, wenn es sich um Permissions handelt, die ihr immer im Paket vergebt, kann es sinnvoll sein, sie zu einem Node zusammenzufassen.
Genaueres dazu findet ihr hier.

Das kann dann z.B. so aussehen:
Code:
pex group admin add permissions.user.(promote|demote).default
pex group admin add permissions.manage.membership.*
pex group admin add -permissions.manage.membership.admin
pex group admin add permissions.(manage|reload)
pex group admin add permissions.manage.groups.list
pex group admin add permissions.manage.(users|groups).(prefix|suffix).*
Sofern ich im weiteren Nodes vergebe, bei denen nichts gegen eine Zusammenfassung spricht, werde ich diese in einer solchen Form angeben.
Mir geht es dabei hauptsächlich um Übersicht, zu große Gruppierungen werde ich entsprechend auf mehrere Nodes verteilen.

Für die PEX-Permissions war es das auch schon. Alle anderen Funktionen/Befehle sollten über die Konsole benutzt werden und vor Eröffnung des Servers abgehandelt sein.
Code:
groups:
  default:
    options:
      default: true
      rank: '900'
      prefix: Gast
    permissions: []
  spieler:
    inheritance:
    - default
    options:
      rank: '800'
      prefix: Spieler
    permissions: []
  admin:
    inheritance:
    - spieler
    options:
      prefix: Administrator
    permissions:
    - permissions.manage.(users|groups).(prefix|suffix).*
    - permissions.manage.groups.list
    - permissions.user.(promote|demote).default
    - -permissions.manage.membership.admin
    - permissions.manage.membership.*
    - permissions.(manage|reload)
schema-version: 1
____________________________________________________________________________________________________

Modifyworld:
(Dokumentation Modifyworld: https://github.com/PEXPlugins/Modifyworld/wiki)

Aktuell kann aber noch niemand etwas auf unserem Server machen. Darum kümmern wir uns nun, indem wir die Modifyworld-Permissions durchgehen.
Bitte beachtet den Hinweis am Anfang dieses Tutorial zu "Modifyworld".

Unserer Gastgruppe möchten wir nun die Permission zum Chatten geben, damit sie sich bemerkbar machen kann.
Persönlich mag ich es auch, wenn Gäste sich umsehen dürfen und dazu Türen, Schalter, Hebel und anderes Zeug benutzen können um sich frei umzusehen. Seit 1.12 funktionieren allerdings die IDs in den modifyworld-Nodes nicht mehr korrekt. (Edit: Mit meiner Version geht's wieder, findet man ganz oben im Spoiler)

Daher suchen wir uns hier die korrekten Materialbezeichnungen für die Sachen, die wir erlauben möchten und die im Node "modifyworld.blocks.interact.<Material>" für die Variable <Material> benutzt werden (!Die Materialnamen können in älteren Spigotversionen abweichen!). Da ich gerne sämtliche Türen, Druckplatten und Schalter erlauben möchte kommt da einiges zusammen.
wenn ich das in Nodes ausschreiben müsste sähe das so aus, wie im folgenden Spoiler:
Code:
modifyworld.blocks.interact.oak_door
modifyworld.blocks.interact.spruce_door
modifyworld.blocks.interact.birch_door
modifyworld.blocks.interact.jungle_door
modifyworld.blocks.interact.acacia_door
modifyworld.blocks.interact.dark_oak_door
modifyworld.blocks.interact.trap_door

modifyworld.blocks.interact.stone_plate
modifyworld.blocks.interact.wood_plate
modifyworld.blocks.interact.gold_plate
modifyworld.blocks.interact.iron_plate

modifyworld.blocks.interact.stone_button
modifyworld.blocks.interact.wood_button

modifyworld.blocks.interact.fence_gate
modifyworld.blocks.interact.spruce_fence_gate
modifyworld.blocks.interact.birch_fence_gate
modifyworld.blocks.interact.acacia_fence_gate
modifyworld.blocks.interact.dark_oak_fence_gate

modifyworld.blocks.interact.lever

modifyworld.blocks.interact.tripwire

Viele davon sehen sich verdächtig ähnlich und da wir oben schon gelernt haben, dass PEX uns Sachen zusammenfassen lässt, sparen wir uns wieder Arbeit und machen das auch.
Wollten wir nur zwei oder drei Sachen aus der Liste erlauben, würden wir sie einfach hintereinander in den Node packen z.B. "modifyworld.blocks.interact.(oak_door|spruce_door)".
Da wir alle Türen erlauben möchten, setze ich stattdessen "*_door" ein. Für so eine "Freikarte" müssen wir uns natürlich sicher sein, dass es keine anderen Materialien gibt die auf "_door" enden, die wir nicht freigeben wollen. Ich schaue noch einmal nach, stelle fest, dass auch die "iron_door" so endet und beschließe, dass das wohl keinen Unterschied macht.
Die anderen Nodes überprüfe ich auch nochmal und vergebe dann:
Code:
pex group default add modifyworld.chat
pex group default add modifyworld.blocks.interact.(lever|tripwire|*_button|*_plate|*_door|*_gate)
Damit sich Gäste noch besser umsehen können, haben wir auf unserem Beispielserver eine Minecartbahn gebaut (richtig Oldschool). Leider können sie diese nicht benutzen. Hier fehlt die Berechtigung, um mit der "Entity" Minecart zu interagieren und sich hineinzusetzen. Bötchen fahren sollen sie auch, daher erlauben wir es mit den beiden Nodes "modifyworld.interact.(minecart|boat)" und "modifyworld.vehicle.enter.*". Beides können unsere Gäste nun benutzen, aber nicht entfernen oder setzen.

Viele Server geben außerdem über Plugins Infobücher. Sollen diese in der Hand haltbar sein, müssen wir auch das erlauben mit "modifyworld.items.hold.*".

Ansonsten erlauben wir noch der Gruppe "spieler" (und damit auch "admin"), im vollen Umfang mit unserer Welt zu interagieren ("modifyworld.*") und sind mit Modifyworld fertig.
Code:
pex group default add modifyworld.modifyworld.items.hold.*
pex group default add modifyworld.interact.(boat|minecart)
pex group default add modifyworld.vehicle.enter.*
pex group spieler add modifyworld.*
Code:
groups:
  default:
    options:
      default: true
      rank: '900'
      prefix: Gast
    permissions:
    - modifyworld.blocks.interact.(lever|tripwire|*_button|*_plate|*_door|*_gate)
    - modifyworld.interact.(boat|minecart)
    - modifyworld.vehicle.enter.*
    - modifyworld.items.hold.*
    - modifyworld.chat
    - modifyworld.chat
  spieler:
    inheritance:
    - default
    options:
      rank: '800'
      prefix: Spieler
    permissions:
    - modifyworld.*
  admin:
    inheritance:
    - spieler
    options:
      prefix: Administrator
    permissions:
    - permissions.manage.(users|groups).(prefix|suffix).*
    - permissions.manage.groups.list
    - permissions.user.(promote|demote).default
    - -permissions.manage.membership.admin
    - permissions.manage.membership.*
    - permissions.(manage|reload)
schema-version: 1
____________________________________________________________________________________________________

Die Permissions von Minecraft, Bukkit und Spigot:

(Dokumetation: https://www.spigotmc.org/wiki/spigot-commands/ - Bukkit und Minecraft verlinkt)

Der letzte noch anstehende Teil sind die Permissions, die Bukkit/Spigot mitbringt.
Hier müssen wir genau aufpassen, da standardmäßig Permissions vergeben sind und negiert werden müssen, wenn wir die entsprechende Aktion verbieten möchten.

! Hinweis für ältere Serverversionen !
Seit Bukkit/Spigot 1.9 heißen alle native Minecraftpermissions "minecraft.<permissions>" anstelle von "bukkit.<permissions>".
Nutzt ihr eine veraltete Version, wie Spigot 1.8.9 und möchtet die angehängte Datei benutzen müssen die Permissions entsprechend angepasst werden.
Hinzu kommt, dass einige Permissions in älteren Versionen nicht existierten und ersetzt werden müssen.​

Nun haben wir die Befehle für "Alle" bzw. "Everybody" kurz durchgeschaut, sind mit der Verwendung von "/me" und "/tell" einverstanden, aber wollen nicht, dass uns jemand den Server klaut und möchten gerne "/version", "/help" und "/plugins" verbieten (meiner Meinung nach Schwachsinn, aber wir sind für dieses Tut überparanoid und machen das jetzt zu Demonstrationszwecken).

Unseren Gästen verbieten wir noch "/me" und "/tell", letzteres können sie Dank Modifyworld sowieso nicht und mit "/me" machen die ja nur Blödsinn, nicht wahr?
Code:
pex group default add -minecraft.command.(help|me|tell)
pex group default add -bukkit.command.(help|version|plugins)

pex group spieler add minecraft.command.(me|tell)
Jetzt müssen wir uns nur noch durch die ganzen coolen "Operator"befehle wühlen und die ausfindig machen, die unsere Sicherheit gefährden könnten. Allen voran die Permission für /op.
Die vergeben wir jetzt nämlich erst gar nicht, alles andere ist Geschmackssache.

Optional könnten wir in den server.properties den Status OP auch noch ein wenig kastrieren und auf Level 2 setzen (op-permission-level=2), womit selbst ein OP niemandem OP geben kann.
Wer ultrahardcoresicher sein will, kann diesen Befehl sogar über die commands.yml ganz entfernen. Da er dann aber auch über Konsole nicht benutzbar ist, muss man sich sicher sein, dass man es so schnell nicht mehr benötigt. (Wer Commandblocks nutzen möchte, macht es besser nicht. Alle anderen haben dadurch keinen Nachteil).
Installiert man später vielleicht WorldGuard, empfiehlt es sich, in dessen Config "deop-everyone-on-join: true" zu setzen. Über die Feinheiten der ganzen Konfigurationsdateien könnte man sicher auch drei Bücher schreiben.

Ich gebe mich hier mal mit einer Nichtvergabe der Permission zufrieden. Damit bleibt die Option, Operatorrechte über die Konsole zu vergeben, falls man doch mal was mit Commandblöcken machen möchte.

Ferner lassen wir die ganzen "/save"-Befehle, "/reload", "/restart", "/stop" und "/debug" nur in der Konsole zu.
Statt "/reload" startet man besser den Server neu und der "/debug"-Befehl muss erst mit Parametern im Startscript aktiviert werden. "/restart" benötigt ein funktionierendes Restartscript und verhält sich ansonsten wie "/stop". Mit den "/save"-Befehlen kann man auch eine ganze Reihe von Unsinn treiben und da die Speicherung unter normalen Umständen funktioniert, lassen wir davon mal die Finger.

Auf jeden Fall sollten wir "admin" erlauben die Whitelist zu aktivieren und verwalten und Spieler zu bannen.
Code:
pex group admin add minecraft.command.whitelist
pex group admin add minecraft.command.deop
pex group admin add minecraft.command.(kick|ban|ban-ip|banlist|pardon|pardon-ip)
Da wir von einem Survivalserver ausgehen, geben wir unseren Spielern keine der "coolen" Permissions wie /give oder /gamemode. Creativeserver benötigen hierfür ggf. sogar eine extra Absicherung gegen NBT-Datenmissbrauch (wieder ein andere Thema). "/defaultgamemode" vergebe ich daher auch nicht.
Optional sind sicher Sachen wie /tp, /kill (erlaubt nur Suizid, nicht das Töten anderer) und /list, aber das mag jeder selber entscheiden. Ich vergebe später /kill und /list an die Spieler.
Für den Beispielserver habe ich ferner der Gruppe "admin" alle coolen "Cheats" vergeben, die man brauchen könnte um das Fußvolk die Spieler zu "beeindrucken". Der Übersichtlichkeit halber in kleinere Pakete verpackt.

Alternativ wäre auch "minecraft.command.*" sowie die Negierung der problematischen Permission möglich gewesen. Aber darin könnten beim nächsten Update Permissions enthalten sein, die man vielleicht nicht möchte. Hier ist mir nachrüsten im Bedarfsfall lieber.
Commands, die fast ausschließlich mit Commandblöcken verwendet werden habe ich nicht verteilt.

Das Endergebnis findet ihr in der angehängten permissions.yml
Verwendung auf eigene Gefahr, alle Angaben ohne Gewähr.

Vielleicht konnte euch dieses Schritt-für-Schritt-Tutorial etwas weiterhelfen, was den Prozess und die Überlegungen angeht, zu einer Permissionsverteilung zu kommen, die nicht allzu einfach auszuhebeln ist (außer ihr verteilt bereitwillig euer Konsolenpasswort, dann kann ich euch auch nicht mehr helfen).

Wenn euch was nicht passt, schreibt es in die Antworten, wenn's euch gefallen hat, ebenso.Sollte mich der Schreibdrang nocheinmal überkommen und keiner hart dagegen argumentieren, überlege ich mir ggf. darauf aufzubauen.
Optionen wären vielleicht: "Teamränge für paranoide Fortgeschrittene", "WorldEdit-/WorldGuardpermissions für Sicherheitsfanatiker" oder "Katzen - Warum sie kuschelige Arschlöcher sind".

EDIT: Abschnitt Modifyworld, Spigotpermissions, Formatierung, Update der angehängten Datei
 

Anhänge

Zuletzt bearbeitet:

SilberRegen

Workaholic
Mitglied seit
23 März 2012
Beiträge
890
Alter
28
Minecraft
SilberRegen
@可愛い Na klar. Ab 50 Likes oder für Premiumnutzer :sheep:

Editierungshinweis:
Ich habe jetzt versucht das Problem mit den IDs in modifyworld zu fixen und bei mir geht's jetzt wieder.
Entsprechend habe ich den Part im Tutorial angepasst auf ein funktionierendes Plugin.

Da ich null Javakenntnisse habe, gebe ich keine Garantie, dass ich dadurch nicht etwas anderes kaputtgemacht habe (vermutlich die Kompatibilität nach unten irgendwo), 'nen Virus erzeugt oder mir selbst ohne es zu merken OP eingebaut habe. Die Profis sind eingeladen meine Glanzleistung zu bestaunen.

Hier der ganze Code, den ich gefrankensteint habe: https://github.com/SilberRegen/Modifyworld/releases/tag/sil.Ver-1.0.5
 
Zuletzt bearbeitet:

SilberRegen

Workaholic
Mitglied seit
23 März 2012
Beiträge
890
Alter
28
Minecraft
SilberRegen
Wie wärs mit nem Tutorial zu LuckPerms?
Habe ich tatsächlich irgendwann vor.

Pex ist zwar immer noch das meistgenutzte Plugin, aber nachdem ich in den letzten Wochen einige Male Luckperms eingerichtet habe, würde ich für neue Server, oder Server die ihr System neu strukturieren wollen, Pex nicht mehr empfehlen wollen.
Außerdem gibt es im Zusammenhang mit PaperSpigot einen nicht ganz so netten Bug, mit dem jeder den Server zum Absturz bringen kann mit Pex.

Bevor ein entsprechenden Tut von mir kommt, habe ich noch ein paar Server auf der Warteliste, die ich auf Luckperms umstellen werde.
 

Andre_601

Minecrafter
Mitglied seit
8 Januar 2016
Beiträge
7
Alter
23
Minecraft
Andre_601
Habe ich tatsächlich irgendwann vor.

Pex ist zwar immer noch das meistgenutzte Plugin, aber nachdem ich in den letzten Wochen einige Male Luckperms eingerichtet habe, würde ich für neue Server, oder Server die ihr System neu strukturieren wollen, Pex nicht mehr empfehlen wollen.
Außerdem gibt es im Zusammenhang mit PaperSpigot einen nicht ganz so netten Bug, mit dem jeder den Server zum Absturz bringen kann mit Pex.

Bevor ein entsprechenden Tut von mir kommt, habe ich noch ein paar Server auf der Warteliste, die ich auf Luckperms umstellen werde.
Ja, LuckPerms ist wirklich ein gutes Plugin.
Ich habe mir sogar überlegt, sowas zu machen....
Ich müsste mir aber überlegen, was ich alles darin behandeln soll...
 

Meyxer

Minecrafter
Mitglied seit
22 November 2017
Beiträge
1
Alter
26
Hallo, mal eine frage zum Config...
wie bekomme ich es denn hin dass PEX clients mit cracked launcher erkennt und mit ihnen interagiert?
Aktuell habe ich das Problem dass Worldguard allen Spielern ohne OP rechten verbietet auch nur irgendwas abzubauen... und das in nicht protecteten bereichen!
In der Permissions.yml werden die cracked user auch gar nicht aufgenommen was pex anbelangt...

LG
 
Allgemein
Hilfe Benutzer
  • ❤️可愛いちゃん️❤️ ❤️可愛いちゃん️❤️:
    Weil sie scheiße alt ist und grundlegende API Methoden einfach fehlen.
  • MrSpock78 MrSpock78:
    Das hat nichts mit Schnittstellen zu tun, wenn der Client ausrastet^^
  • MrSpock78 MrSpock78:
    Sowas kannst du auch in 1.14.x nicht lösen
  • ❤️可愛いちゃん️❤️ ❤️可愛いちゃん️❤️:
    Minecraft hat halt auch keine Serverseitig Verifizierung der Eingaben
  • ❤️可愛いちゃん️❤️ ❤️可愛いちゃん️❤️:
    Meinte aber eher, dass die 1.8 einfach scheiße alt und total verbuggt ist. Das halt als ob man heute Windows 98 nutzt
  • MrSpock78 MrSpock78:
    Die Schnittstellen bleiben die Gleichen... man kann nur das Spielprinzip ändern. Und das versucht Mojang derzeit, um so mehr sich daran beteiligen um so besser.
  • Hadde-chan Hadde-chan:
    Die schnittstellen haben sich nicht geändert owo erzähl das mal den drölf hunderten plugins, die inkompatibel sind xD
  • SirYwell SirYwell:
    Das Video zeigt ziemlich deutlich, wie dumm dieses sog. PvP in Minecraft ist. Ich finde das irgendwie richtig unnötig, wenns nur darum geht, schnell zu klicken
  • MrSpock78 MrSpock78:
    Es bezog sich auf grob "Alle API methoden sind scheisse usw" ... klar ändert sich etwas.
  • MrSpock78 MrSpock78:
    Der Versuch des neuen Combats ist halt genau dass superschnelles Klicken keinen Vorteil mehr bringt^^
  • ❤️可愛いちゃん️❤️ ❤️可愛いちゃん️❤️:
    Ich fand ja Exploits in den Plugins suchen immer deutlich effektiver als schnelles klicken.
  • maybeto maybeto:
    das ist aber schade für @iTz_Proph3t , auch flinker Finger genannt.....
  • iTz_Proph3t iTz_Proph3t:
    Du meinst der flinkeste Finger im Festen?
  • iTz_Proph3t iTz_Proph3t:
    So nennt man mich auch
  • ❤️可愛いちゃん️❤️ ❤️可愛いちゃん️❤️:
    Press F to pay respect
  • Stern☆ Stern☆:
    F F F
  • Matthias Matthias:
    A A A
  • Matthias Matthias:
    Gute Nacht
  • Matthias Matthias:
    Guten Morgen
  • Stern☆ Stern☆:
    Morgen :)
  • HardSoul HardSoul:
    Moin
  • LottaXL LottaXL:
    Moin, moin =)
  • SirYwell SirYwell:
    Guten Morgen
    SirYwell SirYwell: Guten Morgen
    Oben