[ADMN/DEV] PermissionsBukkit v2.0 - Official Default Groups Plugin [1.5.2-R1.0]

Discussion in 'Archived: Plugin Releases' started by SpaceManiac, Jul 17, 2011.

  1. Offline

    SpaceManiac

    PermissionsBukkit - the Official Default Groups Plugin
    Current Version: v2.0
    Find PermissionsBukkit on BukkitDev!

    If you are getting a specific error or cannot determine what is wrong with your permissions file, filing a ticket on BukkitDev will make me much more likely to respond to you; general questions are best to ask in this thread or on the forums on BukkitDev.

    It's been a long time coming, but with the accomplishment of build 1000 Bukkit has finally accomplished a built-in Permissions system (codenamed Superperms). For more info on how they work, and how to integrate them with your plugin, see the official Permissions FAQ. Keep in mind that you should rarely, if ever, have to hook this plugin directly; instead keep things in the realm of checking player.hasPermission("yourplugin.node"). The FAQ thread has more info on how to use Superperms with things like chat prefixes/suffixes.

    Features:
    • Storage of users and groups in plugins/PermissionsBukkit/config.yml.
    • Both users and groups can be assigned individual permissions and parent groups to inherit permissions from.
    • Support for global and per-world permissions.
    • Reload configuration from file with out reloading the plugin.
    • Ability to check if a player has a specific permission node.
    • Ability to dump all permissions a player has and the plugins that set them.
    • Ability to print plugin, description, and default for a given permission node.
    • Ability to modify the permissions of groups and users and the groups of a user in-game.
    • Built-in antibuild via the "permissions.build" node (defaults to allowing anyone to build).
    • A minimalistic bridge from Permissions 3.0 to Superperms is available as a separate plugin, which does not depend on PermissionsBukkit.
    Command Usage:

    Show Spoiler
    PermissionsBukkit uses the command /permissions, with aliases /perms and /perm.

    /permissions reload - reload the configuration from disk.
    /permissions check <node> [player] - check if a player or the sender has a permission (any plugin).
    /permissions info <node> - prints information on a specific permission.
    /permissions dump [player] [page] - prints info about a player's (or the sender's) permissions.
    /permissions setrank <player> <group> - set a player to be in a group with per-group permissions.
    /permissions group - list group-related commands.
    /permissions group list - list all groups.
    /permissions group players <group> - list players in a group.
    /permissions group setperm <group> <[world:]node> [true|false] - set a permission on a group.
    /permissions group unsetperm <group> <[world:]node> - unset a permission on a group.
    /permissions player - list player-related commands.
    /permissions player groups <player> - list groups a player is in.
    /permissions player setgroup <player> <group,...> - set a player to be in only the given groups.
    /permissions player addgroup <player> <group> - add a player to a group.
    /permissions player removegroup <player> <group> - remove a player from a group.
    /permissions player setperm <player> <[world:]node> [true|false] - set a permission on a player.
    /permissions player unsetperm <player> <[world:]node> - unset a permission on a player.

    All commands have in-game help and are usable from the server console.

    Configuration:
    Show Spoiler
    A permission node is a string like 'permissions.build', usually starting with the name of the plugin. Refer to a plugin's documentation for what permissions it cares about. Each node should be followed by true to grant that permission or false to revoke it, as in 'permissions.build: true'. Some plugins provide permission nodes that map to a group of permissions - for example, PermissionsBukkit has 'permissions.*', which automatically grants permissions for all PermissionsBukkit commands. You can also specify false for permissions of this type.

    Users inherit permissions from the groups they are a part of. If a user is not specified here, or does not have a 'groups' node, they will be in the group 'default'. Permissions for individual users may also be specified by using a 'permissions' node with a list of permission nodes, which will override their group permissions. World permissions may be assigned to users with a 'worlds:' entry.

    Groups can be assigned to players and all their permissions will also be assigned to those players. Groups can also inherit permissions from other groups. Like user permissions, groups may override the permissions of their parent group(s). Unlike users, groups do NOT automatically inherit from default. World permissions may be assigned to groups with a 'worlds:' entry.

    The cannot-build message is configurable. If it is left blank, no message will be displayed to the player if PermissionsBukkit prevents them from building, digging, or interacting with a block. Use '&' characters to signify color codes.

    An example configuration file might look like this:
    Code:
    users:
        ConspiracyWizard:
            permissions:
                permissions.example: true
            groups:
            - admin
    groups:
        default:
            permissions:
                permissions.build: false
        admin:
            permissions:
                permissions.*: true
            inheritance:
            - user
        user:
            permissions:
                permissions.build: true
            worlds:
                creative:
                    coolplugin.item: true
            inheritance:
            - default
    messages:
        build: '&cYou do not have permission to build here.'
    

    Permissions:
    Show Spoiler
    PermissionsBukkit checks for the following permission nodes:
    • permissions.build - Allows a player to build. Defaults to true.
    • permissions.help - Allows viewing of usage for /permissions.
    • permissions.reload - Allows use of /permissions reload.
    • permissions.check - Allows use of /permissions reload.
    • permissions.info - Allows use of /permissions reload.
    • permissions.dump - Allows use of /permissions reload.
    • permissions.group.help - Allows viewing of usage for /permissions group.
    • permissions.group.list - Allows use of /permissions group list.
    • permissions.group.players - Allows use of /permissions group players.
    • permissions.group.setperm - Allows use of /permissions group setperm.
    • permissions.group.unsetperm - Allows use of /permissions group unsetperm.
    • permissions.player.help - Allows viewing of usage for /permissions player
    • permissions.player.groups - Allows use of /permissions player groups.
    • permissions.player.setgroup - Allows use of /permissions player setgroup.
    • permissions.player.addgroup - Allows use of /permissions player addgroup.
    • permissions.player.removegroup - Allows use of /permissions player removegroup.
    • permissions.player.setperm - Allows use of /permissions player addgroup.
    • permissions.player.unsetperm - Allows use of /permissions player removegroup.
    Also, the following parent nodes are provided for convenience:

    • permissions.* - Maps to permissions.help, .reload, .check, .info, .dump, and to permissions.group.* and permissions.player.*. Defaults to op.
    • permissions.group.* - Maps to permissions.group.help, .list, .players, .setperm, and .unsetperm.
    • permissions.player.* - Maps to permissions.player.help, .groups, .setgroup, .addgroup, .removegroup, .setperm, and .unsetperm.


    Frequently Asked Questions:
    1. Where are my * nodes? (open)
    Bukkit's Superperms has no built-in concept of a global '*' node that automatically gives all permissions, which is intentional - a player can instead be given all permissions by being given 'op' status (that is, listed in ops.txt). Additionally, individual plugins define a parent node (which could be 'pluginname.*' or 'pluginname.all' or anything else) which maps to whatever subpermissions in that plugin the author desires.

    An example is PermissionsBukkit, which provides three such permissions: 'permissions.group.*' for all /permissions group commands, 'permissions.player.*' for all /permissions player commands, and'permissions.*' for all /permissions commands (including permissions.group.* and permissions.player.*).

    If you are using SuperpermsBridge, you can do something similar to '*' nodes for plugins which use Permissions 2.7/3.1 - see the next FAQ for more information.
    2. How do I use SuperpermsBridge? (open)
    SuperpermsBridge is kind of like FakePermissions for GroupManager or PermissionsBridge for PermissionsEx. Once it's installed, it pretends to be the Permissions plugin and converts any plugins that use Permissions 2.7 or Permissions 3.1 to use Superperms instead.

    You can have PermissionsBukkit without SuperpermsBridge or SuperpermsBridge without PermissionsBukkit if you like, but both of these are limited in functionality. If you install SuperpermsBridge without PermissionsBukkit you will not be able to make use of PermissionsBukkit's groups feature or admin commands, and if you install PermissionsBukkit without SuperpermsBridge, plugins that have not updated to use Superperms directly will not function.

    For plugins that use Permissions 2.7/3.1, you can use the special node 'superpermbridge.*' to give the equivalent of what used to be the '*' node for plugins that do not use Superperms directly. If you don't want to give the * node, you can also use the node 'superpermbridge.pluginname' to do the equivalent of what used to be the 'pluginname.*' node. Once again, these only apply to plugins that SuperpermsBridge handles and not to plugins using Superperms directly.
    3. How do I use the root permissions.yml? (open)
    The file 'permissions.yml' in the root of your server can be used to set up custom parent permissions. Parent permissions are a single node that, when given to a player or group, automatically give all their children node. Here's a simple example:
    Code:
    server.basics:
        children:
            commandbook.motd: true
            commandbook.say: true
            commandbook.say.me: true
            commandbook.time: true
    
    Now, if you give a player the node 'server.basics', they automatically get all the nodes listed here. Children may also say 'false' instead of 'true', in which case giving the parent will remove the child instead of giving it.

    You can also specify a description if you like, which can be used by plugins to provide information on your node (such as PermissionsBukkit's /perm info command). If you want, you can also provide a default, which can be one of "true", "false", "op", or "notop". CraftBukkit will automatically assign everyone, no one (default), ops, or non-ops the children permissions based on the specified default. Without any plugin like PermissionsBukkit, you can use this defaults system as a limited way to assign people permissions. Here's a more complex example:
    Code:
    server.basics:
        description: Basic permissions for My Cool Server.
        default: true
        children:
            commandbook.motd: true
            commandbook.say: true
            commandbook.say.me: true
            commandbook.time: true
    server.admin:
        description: Admin permissions for My Cool Server.
        default: op
        children:
            commandbook.broadcast: true
            commandbook.teleport: true
            commandbook.kick: true
            commandbook.ban: true
    
    You can also define permissions without children, but this is of limited usefulness in permissions.yml (though is important in plugin.yml; see question #6)
    4. How do I switch from (other Permissions plugin)? (open)
    Depends on the Permissions plugin! If you were using PEX's YAML backend, I have a converter done and available on the PermissionsBukkit Tools page. Also available on the tools page is an automatic converter for Essentials GroupManager users.yml and groups.yml files. Automatic converters for Permissions 2.7 and 3.x are on their way, but in the meantime you can still convert your configurations manually.
    5. Where are prefixes and suffixes (or option nodes)? (open)
    Bukkit Superperms has no built-in prefix/suffix settings or non-boolean permission nodes, so individual chat plugins will have to start supporting Superperms in order to make use of non-Permissions-plugin based prefixes and suffixes. Herochat, iChat, and Simple Suffix are all aware of the Superperms update, but in the meantime you can use mChat, which already supports Superperms.

    Once you install mChat and configure the mchat.prefix, mchat.suffix, and mchat.group names in its configuration file (see the example), use PermissionsBukkit to give players or groups the permissions "mchat.prefix.admin", replacing "admin" with whatever node you configured. For example, with an mchat configuration that looks similar to this:
    Code:
    da-name-format: '+prefix+name&e'
    date-format: HH:mm:ss
    message-format: '+prefix+name&f: +message'
    mchat:
        prefix:
            admin: '&4DtK [SO] &7 '
            sadmin: '&9DtK [SA] &7 '
            jadmin: '&aDtK [JA] &7  '
            member: '&cDtK [M] &7 '
    
    You can assign players or groups the mchat.prefix.admin node to get the "SO" prefix, mchat.prefix.sadmin to get the "SA" prefix, and so on.
    6. (Coders) How do I set up my plugin.yml? (open)
    Take a look at this post in Dinnerbone's FAQ for an example. This is a lot like the setup of permissions.yml (see above), but you can also define non-parent permissions (just include description and default and leave out children).
    7. Is PermissionsBukkit outdated? (open)
    No! PermissionsBukkit 2.0 was last updated for 1.3.1-R2.0, is verified to work on 1.4.7-R1.0, and is unlikely to break on future releases.

    Downloads:
    Current Version:

    PermissionsBukkit v2.0 (jar) (details)
    Old Versions:
    PermissionsBukkit v1.6 (jar) (details)

    [​IMG]

    Changelog:

    Friday 7 September 2012 (2.0)
    • Fixed a case-sensitivity issue with setting per-world permissions that could cause some permissions to fail to apply.
    • Added /perm setrank <player> <group> subcommand (alias rank) with per-group permissions (permissions.setrank and permissions.setrank.<group>)
    • Added plugin metrics via http://mcstats.org/plugin/PermissionsBukkitMCStats (disableable in plugins/PluginMetrics/config.yml)
    Wednesday 29 February 2012 (1.6)
    • Fixed some massive issues that were caused due to having uploaded a buggy, in-development version instead of 1.5.
    • Note: If your configuration was messed up as a result of this issue, the new build should gradually correct it as needed.
    Saturday 25 February 2012 (1.5b)
    • Revamped to be compatible with R5.
    • Fixed issues with permissions not carrying properly on world change.
    • Many internal improvements for performance and stability.
    • SuperpermsBridge: in honor of R5 removing deprecated code, SuperpermsBridge is officially gone!
    Monday 18 July 2011 (1.1/1.2)
    • Fix BukkitContrib incompatibility issues.
    • Improved the output of the /perm check command.
    • Fixed issues when 'users:' is not specified in the config file.
    • Fixed the /permissions reload command.
    • SuperpermsBridge: improve wildcard handling; in addition to 'superpermbridge.*' and 'superpermbridge.pluginname', now supported are 'superpermbridge.plugin.*', 'superpermbridge.plugin.subnode.*', and so on.
    Monday 18 July 2011 (1.0/1.1)
    • SuperpermsBridge: adding the special 'superpermbridge.*' and 'superpermbridge.pluginname' nodes (see #2 in the FAQ for details).
    Sunday 17 July 2011 (1.0/1.0)

    • Initial release of PermissionsBukkit v1.0 and SuperpermsBridge v1.0.
     
    madmac, Gesundheit, tripleX and 23 others like this.
  2. Offline

    JohnPulse

    Hi there!
    I want to give my mods permissions to elevate users to a level not equal or superior to them.
    Can this be done simply by giving them the permission.player.setgroup node?
    Regards,
    John
     
  3. Offline

    Casper2b

    Hello everyone,

    I have a little problem. I installed PermissionsBukkit and WorldGuard, I followed many tutorials but when I connect to my server I can't place or remove any blocks even if I put me in admin group or builder group or user group. Please help!
    Here is my plugins folder:
    <Edit by Moderator: Redacted mediafire url>

    Thanks you!

    P.S: Sorry for my english I'm french
     
    Last edited by a moderator: Nov 27, 2016
  4. Offline

    The_Basilisk

    This may sound a bit stupid but... what's the bridge?
     
  5. Offline

    NEREVAR117

    I'm a little confused as to how this all works. I'm trying to translate from Permissions#3 to this, but I'm having some issues understanding things.

    Code:
    users:
        NEREVAR117:
            permissions:
                
            groups:
            - Owner
    groups:
        Member:
            permissions:
                essentials.suicide: true
                essentials.list: true
                essentials.rules: true
                essentials.ping: true
                essentials.sethome: true
                essentials.home: true
        Admin:
            permissions:
                essentials.ban: true
                essentials.kick: true
            inheritance:
            - Member
        Owner:
            permissions:
                *: true
            inheritance:
    Is that format correct?
     
  6. Offline

    Torados

  7. Offline

    Jobi

    @ZerothAngel
    the problem is, that nobody has permissions
     
  8. Offline

    Casper2b

    jobi you talk about what post?

    Any idea about it?

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Nov 27, 2016
  9. Offline

    GoreRanger

    If I have read this thread accurately I'm under the impression that default users have access to any command unless its expressly false in the default permissions. Is this correct?
     
  10. Offline

    Casper2b

    I don't understand I created groups and permissions are defined for all groups
     
  11. Offline

    Heliwr

    No, that is not correct - at least not in my case. It only automatically assigns nodes that the plugin has defined as default access (in which case, if you disagree with the plugin dev, you have to override), or in the case of ops, nodes that the plugin has defined as op access.

    You can double-check what nodes are assigned to a default player by typing 'perm dump <player>' from the console.
     
    Celtic Minstrel likes this.
  12. Offline

    jkmalan

    Hello, all my permissions work perfectly except one, permissions.build. Its not really a matter of it not working but it not doing something I expected/thought it would do.

    config.yml

    Code:
    users:
    
        jkmalan:
    
            permissions:
    
            groups:
    
            - admin
    
        jswizzle4:
    
            permissions:
    
            groups:
    
            - mod
        dafticus:
    
            permissions:
    
            groups:
    
            - mod
        boronne215:
    
            permissions:
    
            groups:
    
            - mod
        stripyneko483:
    
            permissions:
    
            groups:
    
            - mod
    groups:
    
        default:
    
            permissions:
    
                mchat.prefix.default: true
    
                admincmd.player.list: true
    
                admincmd.player.loc: true
    
                admincmd.player.kill: true
    
                admincmd.player.clear: true
    
                admincmd.player.msg: true
    
                admincmd.player.afk: true
    
                admincmd.player.roll: true
    
                admincmd.warp.tp: true
    
                admincmd.spawn.tp: true
    
                admincmd.server.motd: true
    
                admincmd.server.news: true
    
                admincmd.server.rules: true
    
                ChestShop.shop.buy: true
    
                ChestShop.shop.sell: true
    
                commandSigns.use: true
    
                iConomy.holdings: true
    
                iConomy.payment: true
                lwc.protect: true
    
            world:
    
                StaffWorld:
                    permissions.build: false
                Survival:
    
                    admincmd.player.loc: false
    
                    admincmd.player.clear: false
    
                    admincmd.player.roll: false
    
                    ChestShop.shop.buy: false
    
                    ChestShop.shop.sell: false
    
                    commandSigns.use: false
    
                    iConomy.holdings: false
    
                    iConomy.payment: false
    
                    lwc.protect: false
    
                    permissions.build: true
                Capital:
                    permissions.build: false
        user:
    
            permissions:
    
                mchat.prefix.default: false
    
                mchat.prefix.user: true
    
                admincmd.player.ip: true
    
                admincmd.tp.to: true
    
                admincmd.tp.from: true
    
                admincmd.tp.home: true
    
                admincmd.maxhomebyuser.2: true
    
            world:
    
                StaffWorld:
    
                    permissions.build: false
    
                Survival:
    
                    admincmd.player.ip: false
    
                    admincmd.tp.to: false
    
                    admincmd.tp.from: false
    
                    admincmd.tp.home: false
    
                    admincmd.maxhomebyuser.2: false
                    permissions.build: true
                Capital:
                    permissions.build: true
            inheritance:
    
            - default
    
        host:
    
            permissions:
    
                mchat.prefix.user: false
    
                mchat.prefix.host: true
    
                admincmd.item.color: true
    
                admincmd.player.loc.other: true
    
                admincmd.player.kick: true
    
                admincmd.player.ip.other: true
    
                admincmd.player.mute: true
    
                admincmd.player.superbreaker: true
    
                admincmd.player.played: true
    
                admincmd.tp.players: true
    
                admincmd.tp.location: true
    
                admincmd.tp.back: true
    
                admincmd.warp.tp.other: true
    
                admincmd.server.repeat: true
    
                admincmd.player.noreset: true
    
                lagmeter.*: true
    
                magiccarpet.mc: true
    
                magiccarpet.ml: true
    
                permissions.build: true
    
            world:
    
                StaffWorld:
                    permissions.build: true
    
                Survival:
    
                    admincmd.item.color: false
    
                    admincmd.player.loc.other: false
    
                    admincmd.player.ip.other: false
    
                    admincmd.player.mute: false
    
                    admincmd.player.superbreaker: false
    
                    admincmd.tp.players: false
    
                    admincmd.tp.location: false
    
                    admincmd.tp.back: false
    
                    admincmd.warp.tp.other: false
    
                    admincmd.server.repeat: false
    
                    admincmd.player.noreset: false
    
                    magiccarpet.mc: false
    
                    magiccarpet.ml: false
                    permissions.build: true
                Capital:
                    permissions.build: true
            inheritance:
    
            - user
    
        mod:
    
            permissions:
    
                mchat.prefix.host: false
    
                mchat.prefix.mod: true
    
                admincmd.item.add: true
    
                admincmd.item.add.other: true
    
                admincmd.item.more: true
    
                admincmd.item.repair: true
    
                admincmd.item.repair.other: true
    
                admincmd.player.clear.other: true
    
                admincmd.player.ban: true
    
                admincmd.player.freeze: true
    
                admincmd.player.invisible: true
    
                admincmd.player.np: true
    
                admincmd.player.god: true
    
                admincmd.player.fly: true
    
                admincmd.player.feed: true
    
                admincmd.warp.create: true
    
                admincmd.server.uptime: true
    
                admincmd.invisible.notatarget: true
    
                admincmd.player.bypass: true
    
                admincmd.spec.notprequest: true
    
                admincmd.server.lockdown: true
    
                admincmd.maxhomebyuser.4: true
    
                iConomy.holdings.others: true
    
                iConomy.accounts.create: true
                iConomy.accounts.remove: true
    
                iConomy.accounts.status: true
    
                lwc.mod: true
    
                superpermbridge.worldguard: true
            world:
    
                StaffWorld:
    
                Survival:
    
                    admincmd.item.add: false
    
                    admincmd.item.add.other: false
    
                    admincmd.item.more: false
    
                    admincmd.item.repair: false
    
                    admincmd.item.repair.other: false
    
                    admincmd.kit.smod: true
    
                    admincmd.player.clear.other: false
    
                    admincmd.player.freeze: false
    
                    admincmd.player.invisible: false
    
                    admincmd.player.np: false
    
                    admincmd.player.god: false
    
                    admincmd.player.fly: false
    
                    admincmd.player.feed: false
    
                    admincmd.warp.create: false
    
                    admincmd.invisible.notatarget: false
    
                    admincmd.spec.notprequest: false
    
                    admincmd.maxhomebyuser.4: false
    
                    iConomy.holdings.others: false
    
                    iConomy.accounts.create: false
    
                    iConomy.accounts.remove: false
    
                    iConomy.accounts.status: false
    
                    lwc.mod: false
    
                    superpermbridge.worldguard: false
    
                Capital:
    
            inheritance:
    
            - host
    
        admin:
    
            permissions:
    
                mchat.prefix.mod: false
    
                mchat.prefix.admin: true
    
                admincmd.*: true
    
                changename.own: true
    
                changename.other: true
    
                changename.get: true
    
                ChestShop.shop.create: true
    
                ChestShop.shop.admin: true
    
                commandSigns.create: true
    
                commandSigns.super: true
    
                annotate.view: true
    
                annotate.ann: true
    
                annotate.override: true
    
                ChestShop.shop.buy: true
    
                ChestShop.shop.sell: true
    
                commandSigns.use: true
    
                iConomy.holdings: true
    
                iConomy.payment: true
    
                iConomy.holdings.others: true
    
                iConomy.accounts.give: true
    
                iConomy.accounts.take: true
    
                iConomy.accounts.set: true
    
                iConomy.accounts.status.set: true
    
                iConomy.accounts.remove: true
    
                iConomy.accounts.purge: true
    
                iConomy.accounts.empty: true
    
                iConomy.accounts.create: true
    
                iConomy.accounts.status: true
    
                lagmeter.*: true
    
                lwc.admin: true
    
                magiccarpet.mc: true
    
                magiccarpet.mcs: true
    
                magiccarpet.ml: true
    
                magiccarpet.mr: true
    
                permissions.*: true
    
                permissions.build: true
    
                setrankpb.rankall: true
    
                superpermbridge.multiverse: true
    
                superpermbridge.worldedit: true
    
                superpermbridge.worldguard: true
    
            inheritance:
    
    messages:
    
        build: '&cYou are not allowed to build at this rank!'
    
    My goal was to allow default group to only build in Survival world and then let user inherit all the same perms except a few extras and allow users to only build in Capital and Survival worlds. Then finally, host and mod can build anywhere. Unfortunately, after using several variations, either the groups can build in every world or none...
    Anyone help me?

    P.S. Ignore the spaces, they dont actually exist in the real config :p

    @Jobi
    Under the first group in the config, change the permissions node superpermsbridge to superpermbridge and as well, add a :true to the last two nodes in that same group.

    @JohnPulse
    That will not at all work, they will have full control of groups if you do that. Instead, take a plugin like SetRankPB and it will help you out more on this. It allows you to set ranks faster and also specify a limit on rank setting. :D

    @Casper2b
    I worked on your config a little. I saw no errors, but I tweaked some things. I shortened ALOT of nodes using the superpermbridge, and I removed the default permissions that come with the template. Something may have been interfering. Anyway, heres a modified version of the config.yml. Place this in the permissionsbukkit folder and see what happens.

    config.yml

    Please tell me how it goes :D

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jul 14, 2016
  13. Offline

    Heliwr

    Hi jkmalan, I have a similar setup (five worlds, with users building in two, SU adding another two, and VIP adding the final world) and got it working well with the 1.2k build. What I did was set permissions.build: false globally for the default group, and then used the worlds sections for overriding individual worlds with permissions.build: true.

    Code:
    groups:
        default:
            permissions:
                permissions.build: false
                server.guest: true
                chat.prefix.guest: true
                group.default: true
            worlds:
                fish:
                    nocheat.checks.moving.flying: true
                    magiccarpet.mc: true
        User:
            permissions:
                server.user: true
                chat.prefix.guest: false
                chat.prefix.user: true
                group.default: false
                group.user: true
            worlds:
                sanguine:
                    permissions.build: true
                hades:
                    permissions.build: true
            inheritance:
            - default
        SU:
            permissions:
                server.su: true
                chat.prefix.user: false
                chat.prefix.su: true
                group.user: false
                group.su: true
            worlds:
                shiny:
                    permissions.build: true
                laconic:
                    permissions.build: true
            inheritance:
            - User
        VIP:
            permissions:
                server.vip: true
                permissions.build: true
                chat.prefix.su: false
                chat.prefix.vip: true
                group.su: false
                group.vip: true
            inheritance:
            - SU
        Mod:
            permissions:
                server.mod: true
                chat.prefix.vip: false
                chat.prefix.mod: true
                group.vip: false
                group.mod: true
            inheritance:
            - VIP
        Admin:
            permissions:
                server.admin: true
                chat.prefix.mod: false
                chat.prefix.admin: true
                group.mod: false
                group.admin: true
            inheritance:
            - Mod
        Owner:
            permissions:
                server.owner: true
                chat.prefix.admin: false
                chat.prefix.owner: true
                group.admin: false
                group.owner: true
            inheritance:
            - Admin
    messages:
        build: '&cYou do not have permission to build here.'
    users:
        ...
    
     
    Celtic Minstrel likes this.
  14. Offline

    jkmalan

    @Heliwr
    Thanks lots and lots! Im not sure if i've tried that, but it should work. Thanks again! :D
     
  15. Offline

    CatLingYun

    Hello, I have a question~
    Can I set group-specific :false permissions in setgroup command?
    What I mean is preventing an admin or mod from giving himself "owner" or "vip" privileges.
    Like permissions.player.setgroup.groupname: false
     
  16. Offline

    jkmalan

    @CatLingYun
    No, not that I know of, but a separate plugin, SetRankPB can help you with that! :D

    @Heliwr
    It still doesn't work, same as before. I have no idea whats wrong. Any other thoughts?

    How bout anyone else? Thoughts on my problem? (Look up a few post)

    :p I had in the config, world instead of worlds. Im a complete failure unworthy of permissions! Anyway, I can still thank you because I saw this in your config and was baffled by my stupidity!
     
  17. Offline

    Vezorock

    How can i transfer my permissions 3 stuff to bukkitperms?
     
  18. Offline

    Galameth

    First off, reading helps. The LAST FIVE PAGES have been people asking that exact question. And the amswer EVERY single time is ::::

    Do Not Use permissions.*: true

    IT....DOES....NOT....WORK.

    you MUST manually configure every permissions and above all else, you MUST specify

    permissions.build: true

    You cannot use permissions.*: true AND permissions.build: true in the same config. Take the .* out all together for everything and enter it line for line for each user.



    Yes, you are correct so long as you use the ": true" calling.


    No, bridge is absolutely not necessairy, instead, take the 5 minutes to redo your commands in the PROPER format instead of using a cheat to fake that you did it.

    Much less headache and it's guaranteed to work.


    That i'm aware of, no, you have to use the /reload command, though I would imagine it would not be too far fetched to write something that auto sends that command every so often.

    Does it work before hand? Or are you saying it loads but you cannot actually use commands? Or are you saying that USING the command breaks it?

    The only issue you should have is that *: true.

    In essence youll have to post a list of all commands you want set to true in the Owner group. So far, anyone using:

    .*
    *
    *.
    or any form of * has caused obscene trouble to no end.

    Otherwise, yes, its formatted properly, spaces and all. If something does not work however, post it :p

    One last word of advice, you need a group called "default" which is where it puts any user not added toa specific group, and you'll want to create another list in there of every single command node and set them to false.

    I.E. Unverified guests will have no access to any commands.

    Your safest bet to ensure there are no loopholes is to use /permissions dump player <playername> <pagenumber> to list ALL available commands to users and see where you have holes (can anyone op themselves for instance, or can they move themselves from one group to another!)

    The security rule of thumb is, if there is a command, set something for it.

    You have about 1/8th of the available commands that have a specific "allowed" "not allowed" setting listed. the rest? You have no setting for and odds are it defaulted them all to "allowed".

    Nasty things like remove.whitelist or bukkit.command.banip

    If you have no setting specified, there is a chance that it can be used unauthorized.

    I absolutely agree. However, for a small server its often the easiest way, and what alot of people are doing is going from a small server to realising they are tired of people /giving everything or what have you and deciding to upgrade to individual permissions, thereby leaving people opped thinking that the permissions will auto disallow what op allows. It causes a headache if you don't know how many commands are actually available. A couple of pages ago when I was listing the full permissions.permissions node list people were suprised at the commands they flat out knew nothing about and thought they had "locked down" everything.

    They didn't even SEE the bukkit.command nodes.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Sep 9, 2018
  19. Offline

    Heliwr

    It does work actually, I am running the 1.2k build with permissions.build: true for users and permissions.*: true for admins and it works just fine.
     
  20. Offline

    Galameth

    Perhaps not in your case, but I assure you., it is. If you create a player, it auto adds them to a group if one is not implicitly defined. In this case, commands that do NOT have an implicit setting are defaulted to "true/allowed"

    Especially if you are running an offline server and less the savory minecraft client users are bypassing the minecraft.net auth.

    By default, anyone who is OP does indeed have the ability to use /permissions and set their own groups UNLESS the default group they are added to IMPLICITLY states their group does not. Same goes for all plugins, managed or not.

    I do highly stress the use of the /permissions dump player <playername> <pagenumber> command as stated. And I do so repeatedly. It's the most valuable tool you have against leaks.


    You are also lucky in the permissions.* then. if you look at the last 6 or so pages, ALL of them would not work untill it was removed and the actual command was used instead. Care to give info on your build/config?
     
  21. Offline

    Heliwr

    I fail to see the problem - many plugins give ops access to all functionality anyways, and if all this plugin is doing is respecting the plugin developer's definitions of who should have access to what commands then it is doing nothing wrong. I do agree that you should regularly make use of the dump command so you know what is going on.

    Build 1.2k
    Code:
    groups:
        default:
            permissions:
                permissions.build: false
                server.guest: true
                chat.prefix.guest: true
                group.default: true
            worlds:
                fish:
                    nocheat.checks.moving.flying: true
                    magiccarpet.mc: true
        User:
            permissions:
                server.user: true
                chat.prefix.guest: false
                chat.prefix.user: true
                group.default: false
                group.user: true
            worlds:
                sanguine:
                    permissions.build: true
                hades:
                    permissions.build: true
            inheritance:
            - default
        SU:
            permissions:
                server.su: true
                chat.prefix.user: false
                chat.prefix.su: true
                group.user: false
                group.su: true
            worlds:
                shiny:
                    permissions.build: true
                laconic:
                    permissions.build: true
            inheritance:
            - User
        VIP:
            permissions:
                server.vip: true
                permissions.build: true
                chat.prefix.su: false
                chat.prefix.vip: true
                group.su: false
                group.vip: true
            inheritance:
            - SU
        Mod:
            permissions:
                server.mod: true
                chat.prefix.vip: false
                chat.prefix.mod: true
                group.vip: false
                group.mod: true
            inheritance:
            - VIP
        Admin:
            permissions:
                server.admin: true
                chat.prefix.mod: false
                chat.prefix.admin: true
                group.mod: false
                group.admin: true
            inheritance:
            - Mod
        Owner:
            permissions:
                server.owner: true
                chat.prefix.admin: false
                chat.prefix.owner: true
                group.admin: false
                group.owner: true
            inheritance:
            - Admin
    messages:
        build: '&cYou do not have permission to build here.'
    users:
        ...
    
    In addition, the server.admin node in permissions.yml contains permissions.*: true and no other explicit permissions nodes are listed. Admins and myself can use all of the commands as expected.
     
  22. Offline

    Galameth

    Perhaps, but we have no other explanation or experience other then that what I suggested works irregardless of and independent of using *'s

    Also mind you, permissions.yml in root gets overruled if there are invalid commands/nodes in it.

    Apparently for some it works, for others it doesn't, but specifying individual settings works no matter what. So its the route I suggest. :p Two sides of a coin, different faces, same coin and result.


    As for the ops? Because essentials or other plugins like it offer many commands that an op would have and a LOT of commands ops do not and some should not have. If you have varying levels of admins on a server, giving them op status they recieving FULL access to commands is ludicrous. It's more reasonable, however, to avoid opping anyone and use a secondary plugin such as essentials, to manage who has how much ability with the server whils at the same time letting base users have some functionality command wise.

    As it stands, there is either noone gets any commands or people get opped and have access to all commands. If that made sense?
     
  23. Offline

    Heliwr

    I actually don't see the point of opping anyone, that is what permissions are for. My ops.txt is empty, I don't even put myself in there. But theoretically opping someone implies a high level of trust, and as such it makes sense to me that ops would have access to the whole kit.
     
  24. Offline

    Casper2b

    Thanks a lot, before use it Iwould know why you dellete the nodes about worldedit in buider group (I'm a bit curious:))
     
  25. Offline

    BannerFigurezZz

    Hi guys
    I am new to setting up permissions so I tried but something went wrong and I can't figure out what.
    Could someone look at my permissions setup a find what's wrong(its a very small one so)?

    # PermissionsBukkit configuration file
    #
    # A permission node is a string like 'permissions.build', usually starting
    # with the name of the plugin. Refer to a plugin's documentation for what
    # permissions it cares about. Each node should be followed by true to grant
    # that permission or false to revoke it, as in 'permissions.build: true'.
    # Some plugins provide permission nodes that map to a group of permissions -
    # for example, PermissionsBukkit has 'permissions.*', which automatically
    # grants all admin permissions. You can also specify false for permissions
    # of this type.
    #
    # Users inherit permissions from the groups they are a part of. If a user is
    # not specified here, or does not have a 'groups' node, they will be in the
    # group 'default'. Permissions for individual users may also be specified by
    # using a 'permissions' node with a list of permission nodes, which will
    # override their group permissions. World permissions may be assigned to
    # users with a 'worlds:' entry.
    #
    # Groups can be assigned to players and all their permissions will also be
    # assigned to those players. Groups can also inherit permissions from other
    # groups. Like user permissions, groups may override the permissions of their
    # parent group(s). Unlike users, groups do NOT automatically inherit from
    # default. World permissions may be assigned to groups with a 'worlds:' entry.
    #
    # The cannot-build message is configurable. If it is left blank, no message
    # will be displayed to the player if PermissionsBukkit prevents them from
    # building, digging, or interacting with a block. Use '&' characters to
    # signify color codes.

    users:
    Joris:
    permissions:
    permissions.*: true
    bukkit.*: true
    lwc.*: true
    waypoint.*: true

    groups:
    - admin

    Zhpd2
    permissions:


    groups:
    - User

    Floris
    permissions:


    groups:
    - User

    Thijn
    permissions:


    groups:
    - User

    Marijn
    permissions:


    groups:
    - User

    Maikel
    permissions:


    groups:
    - mod

    DoanII
    permissions:


    groups:
    - User
    groups:

    admin:
    permissions:
    permissions.*: true
    bukkit.*: true
    lwc.*: true
    waypoint.*: true
    inheritance:
    - user

    user:
    default: true
    permissions:
    permissions.build: true
    lwc.remove : true
    lwc.create: true
    lwc.unlock : true
    waypoint.home: true
    waypoint.spawn: true
    waypoint.basic.*: true
    waypoint.home.*: true
    waypoint.warp.list: true
    waypoint.warp.acces.default: true
    waypoint.teleport: true


    inheritance:

    user:
    default: true
    permissions:
    permissions.build: true
    lwc.remove : true
    lwc.create: true
    lwc.unlock : true
    waypoint.home: true
    waypoint.spawn: true
    waypoint.basic.*: true
    waypoint.home.*: true
    waypoint.warp.list: true
    waypoint.warp.acces.default: true
    waypoint.teleport: true
    waypoint.create: true
    waypoint.delete: true

    inheritance:


    messages:
    build: '&cYou do not have permission to build here.'
     
  26. Offline

    Galameth

    Your spacing. The number of spaces before things is EXTREMELY important.

    Code:
    users:  #no spaces before users
        galameth:        # MUST contain 4 spaces before name
            permissions: # MUST contain 8 spaces before this
            groups:      # MUST contain 8 spaces before this
            - admin      # MUST contain 8 spaces before, a - and 1 space after it
        cadfael:        # before the group name
            groups:
            - user
        lomion047:
            groups:
            - user
        permtest:
            groups:
            - admin
        modeltxinfamy:
            groups:
            - user
    same with the groups:

    Code:
    groups:            # NO spaces before groups
        default:
            permissions:
                permissions.build: false      # MUST have 12 spaces before these
                godPowers.godmode: false
                godPowers.godmodeOnLogin: false
                godPowers.die: false
                godPowers.slay: false
                godPowers.jesus: false
                godPowers.heal: false
                godPowers.maim: false
                godPowers.inferno: false
                godPowers.superjump: false
                godPowers.zeus: false
                godPowers.gaia: false
                godPowers.vulcan: false
                godPowers.demigod: false
                godPowers.commands: false
                godPowers.godtools: false
                godPowers.hades: false
                gianttrees.build: false
                gianttrees.undoall: false
                gianttrees.reload: false
                gianttrees.nolimit: false
                gianttrees.custom: false
                gianttrees.customdangerous: false
        admin:

    Also, not gonna start it, but you have permissions.* too XD
     
  27. Offline

    BannerFigurezZz

    Thanks ill go try this out

    but the star means all the command from that plugin right?

    Right now I have this, corrected my dumb they all have a * command mistake and now its gives another weir error
    while scanning a simple key in "<unicode string>", line 36, column 5: Zhpd2

    my current:


    but could someone please check this on what my mistake(s) are, like I said i am new to the permissions thing and would like to use it

    After some fixing and trying I now have left:

    ERROR: mapping values are not allowed here in "<unicode string>", line 95, column 20: permissions:

    What does it mean

    I forgot current version looks like this(link)
    so please someone help me get this working

    http://pastebin.com/qzxNJjTg

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jul 14, 2016
  28. Offline

    tzorkr

    hello,

    if there a possibility to become all new peoples on server in a special group (user) automaticly?

    if i use
    ingame: /permissions player setgroup playername user
    why it will not be saved? after server restart its undon.

    greetingz

    thomas
     
  29. Offline

    BannerFigurezZz

    So I have it finally working now, after a day of hard work
    thanks for the startup help.
    One thing though could you guys check if I did it right?

    here's the pastebin link

    http://pastebin.com/bG3Bmyj6
     
  30. Offline

    jkmalan

    @Casper2b
    I saw that you had superpermbridge installed so I used superpermbridge.worldedit which is a special node that gives all worldedit commands. You can use superpermbridge.pluginname to give everything that plugin has to offer. :D

    @BannerFigurezZz
    Your config confused me, alot. So i fixed it up for you. Some things you put in there were non-existant. I did the best I could with it. Also, one problem that most people seem to have, is that you NEED a default group or else permissionsbukkit won't know where to place new users. Anyway, the config can be downloaded here:

    config.yml

    And you have to remove the (2) after the file name, or else it won't work. :)
    P.S. I just posted but I looked at your new config and still some errors. Try this one :D

    @tzorkr
    Yes, just change the name of the group 'user' to 'default' and everyone new who joins the server will be in that group.
     
  31. Offline

    tzorkr

    ah ok i will test this many thx :)
     

Share This Page