Permissions FAQ

I would think groups provide the advantage of assigning common permission sets to a single security principal, then adding other security principals (users) to that group automatically grants them all the already assigned permissions.

If I have to assign new users their own permissions in each plugin I'm running each time a new user needs them, that's an administrative nightmare for me.

And the most common "simple" scenario to me is Admins, Mods, Players, at least three groups. I'm also not sure why groups were seemingly discarded as irrelevant for this feature. It really seems complimentary.

Also, I can think of at least a few "common" situations where a player would want to be able to mess with groups and their members... Things like regions come immediately to mind where a region owner would want to work with a list of users and groups to assign them access. The idea that the player would have to somehow be given an interface to assign each user by name a permission by name is unfathomable on the amount of sheer typing that player would have to do in-game versus leveraging a group solution where they might have to instead just type: "/region add [Group1]"

If the suggestion is the region plugin implement it's own group solution, then that group is isolated to that plugin and other plugins can not leverage it and you now have plugin related groups each stored in their own repository. I'm not sure how that's better.

I'm also not sure what is wrong with wildcarded permissions. The wildcard is simply a textual representation of inheritance flag. Inheritance is very common in permissions systems and provides flexibility. I seemed to find an implementation for such: https://github.com/EdGruberman/Acce...src/edgruberman/accesscontrol/Policy.java#L64
https://github.com/EdGruberman/Acce.../edgruberman/accesscontrol/Privilege.java#L57

I don't really see anything inherently wrong with wildcards, but there are situations in which they can cause problems, and the universal wildcard '*' is the most prone to these. It might be nice to have a method in the Bukkit API and/or the plugin.yml to use as a sort of shorthand for creating wildcard permissions, but having it automatically recognize wildcard permissions isn't necessarily what you want in all cases.

Everyone needs to go back, read the FAQ again, and wake up from this nightmare. This simply isn't true, and I'm not going to post about it anymore.

Hmm this update is even more of a nightmare for me than i had hoped as I'm both a dev AND a server admin. none of this will work with my load without stackoverflows nor is it simple enough...I think i'm going back to coding Cerberus and Synapse and ridding myself of this nightmare until it is fixed

Well. We could also omit groups from windows and assign permissions to every single user, but that's not practical. How would I have a GUI where I can assign additional permissions to my admins? List all users that have a pseudo-group-permission and use that "group" to add additional? How do I list all Groups?

If the bukkit permissions will not provide all features that are common to all permission systems we have today, like groups and we have to add references to those plugins again, why bother with bukkit permissions anyway? If I need permissionProxy.getGroup(player) anyway, you can be sure this will have a has() method too.

Also, why does bukkit cache the permissions when the plugin itself may have a better idea how to cache it efficient? like when it implements groups and permissions are attached to those groups, the plugin only needs to cache user/group and group/permissions and not a copy of the permissions for every user, because it has no clue that the permissions are the same for every user in the group.

And did I get this right that I can't find out what the permissions of the user are in another world, unless I teleport him there first?

As I said earlier, the FAQ simply says "you have no groups, no wildcards ok bye", without explaining properly what options we have instead.

For instance, the only sane way of doing block group permissions is to dynamically load them all into a super node for that group and assign that to users (the option is the always favourite loop through every god damm permission to give that user). Which then begs the question of how unsetting/setting nodes which share children will be handled.

I think unsetting a node with children will result in setting each of the children to the state opposite the one specified by the parent.

do you ever intend to break the functionality of currently available permissions plugins within bukkit to force people to use bukkits permissions?

having to add the 64 permissions nodes for minecartmania signs instead of just adding minecartmania.signs.* seems very counterintuitive.

You should not have to do this, as long as Minecart Mania does its job properly. There may not be wildcards, but I think plugins will generally try to mimick the idea of wildcards.

how then would i go about replicating minecartmania.signs.* without having to type all 64 nodes into a group.
as the developer for minecart mania won't be back until september.

If MM isn't updated to Bukkit.perms, it uses the old system. So where's the problem?
If you use SuperpermsBridge by SpaceManiac, it has the option to mimic the wildcard behaviour.

But what if i don't want to use permissions on my server? can i just ignore it, so things will stay as they where before this? (most defaulting to either op or everyone)

So a negated node would go to allowed? That's really great, people getting superpick where they shouldn't.

Your right he probably does not have time but I'm willing to take my chances and he he can not write the config file could you do it?

I'm totally lost between what Superperms, PermissionsBukkit, and what the difference is


Also, when we're on #1000 can we still use Permissions 3.0?

This can't be right. It will return to the default behaviour which is returning false for everything... like when you never set the node.

Ehr? Minecart Mania is a plugin which uses Permissions. Now why has Minecart Mania to bother with the wildcards? I mean, has the developer of Minecart Mania to add a permission minecartmania.signs.* and manually add all permissions? This is very prone for tiny copy & waste errors (added new permission and forgot to add it to the wildcard permissions).

Instead this is the job of the underlying permissions plugin, to handle this.

Fabian

priorities?

what happens if I assign those two permissions:

Code:

this:
  children:
    child1: true
    child2: false
that:
  children:
    child1: false
    child2: true

I see, does this happen because the order is kept or because the system throws the information away that these perms were set by this & that and only keeps track of the child perms?

I'm still using Permissions 3.x without any issues.

After 5 pages all I can say is..... UGG. I was definitely expecting Bukkit to implement a full-featured group management system and it sounds like this is just the bare bones API to storing permission nodes. I have to agree with @Mixcoatl , this is not the answer to my server admin woes.

I still don't understand why Bukkit can't just absorb Permissions 3.x and simplify the commands to:
/setgroup (add/remove) (player) (group)
/setinfo (group/player) (node) (value)
/setperm (add/remove) (group/player) (node)
/addgroup (group) (default?) (inheritance)
/removegroup (group)

But I understand now this wasn't the goal and the new node system will help. I hope SpaceManiac's PermissionsBukkit becomes the standard because as a server admin I'm tired of having to keep changing plugins to do something that Hmod easily did over a year ago (no offense).

One final question: Who actually would be modifying the permissions.yml file? Would that be done by Bukkit, Admins, or Permission-Management plugins like PermissionsBukkit?

Could the function be emulated by having

"group.groupname"

permission nodes?

"group.operator" would be a child of "group.admin"

Being unable to change parent/child arrangements makes it less flexible though.

@Dinnerbone

So when a superperm is removed any children it shares are recalculated properly?

That doesn't address group metadata issues, which is the ONLY thing groups are usually nessecary for outside of setting permissions

Well that's a nice feature. Seems the only real gripe now is the lack of a group level metadata API, for chat prefixes and such.

So if i get this correctly:
Permissions yml:

Code:

permissions:
    doorman.*:
        description: Gives access to all doorman commands
        children:
            doorman.kick: true
            doorman.ban: true
            doorman.knock: true
            doorman.denied: false
    doorman.kick:
        description: Allows you to kick a user
        default: op
    doorman.ban:
        description: Allows you to ban a user
        default: op
    doorman.knock:
        description: Knocks on the door!
        default: true
    doorman.denied:
        description: Prevents this user from entering the door

This just enables the commands,, then i use a different plugin to define who can use them?

If not how would i create groups in the permissions.yml?

I had Admin, Mod, VIP, member and guest

I Fail to grasp how to create groups
But as far as i can see:
Permissions:
This states what the plugin is? --- doorman.*:
description: Gives access to all doorman commands
This states what commands/nodes the plugin uses? --- children:
doorman.kick: true
doorman.ban: true
doorman.knock: true
doorman.denied: false

This can be handled by the plugins themselves. The only thing you need the prefix for is chat display; the chat plugin's config can have a section as such:

Code:

groups:
  - mygroups.clan1 #this is defined by the admin in permissions.yml, it's just a flag for the group
      prefix: '[Clan 1]'
      suffix: '[The best!]'
      flood-limit: 10
      whatever-else: 'w00t'
  - server.groups.admins #or you could do it like this
      prefix: '=ADMIN='
  - moderators #even like this, but make sure you don't trample a plugin's name!
      prefix: '-mod-'
  - com.fouramsminecraftserver.groups.builders #this is probably safest
      suffix: '/b/'

The nodes here don't need to be the ones I've assigned; you can use anything you want, including nodes declared by other plugins (as long as they'll only be true for that particular group). Remember, the example above shows a section of the config.yml of the chat plugin (HeroChat, iChat, whatever), and NOT the permissions.yml file, either Bukkit's or a permission manager's.

This seems to be an attempt at a distinction between configuration and permission; which has the advantage of preventing confusion and mis-configuration; imagine a permission overrides a config.yml setting, or vice-versa (depends on how the plugin is coded!) unintentionally. If nothing else, it's a support nightmare for devs and downtime for the servers while the issue is resolved.

I was thinking of recommending we set an unofficial standard of server.groups.whatever in permissions.yml for group flags, and then assigning those nodes true using your permissions manager of choice to the applicable group; but in reality, as long as the config.yml for plugins that need to determine groups are flexible enough to ask which node represents which group, admins can use any naming convention they prefer.

On another note, I agree with some of the recent posts here, however, on the following issues:

• How to we determine and/or set the permissions of offline users without accessing the permission-managing plugin directly? You could queue set-requests until the user comes online; but this is extra work with Persistence and would be much better handled as integrated with the API; this also doesn't solve the issue of querying an offline user's permissions.
• How do we query for a list of users who have a certain permission, as opposed to querying for a node in relation to a specific player?

If we can solve these two issues, SuperPerms is at least as powerful as current systems, and in reality is likely much more versatile.

Nope, stop right there. This example you see is what goes inside a plugin to let Bukkit know what permissions the plugin is going to be using up-front. It's likely similar to what you can define in permissions.yml, however; I have not yet seen an example of a permissions.yml

Could somebody post a short example of a proper Permissions.yml? I keep failing when I try and set it up so that I don't have to type dozens of repetitive permissions in the config.yml for each group.