ACL and Groups/English

From Mumble Wiki
Jump to: navigation, search

Groups

Groups are tied to a specific channel, but can also be inherited by subchannels. Groups are convenient ways to administer channels; set up the ACLs on the top of the tree that should have similar privilege structure, and just change the group memberships on subchannels.

For each channel, a group has 3 pieces of data. The list of players to add to the group, the list of players inherited from the same group on the parent channel, and the list of players to remove from the group.

A group will only inherit players from the parent if Inherit is set true and the group was marked Inheritable on the parent. Most of the time you want both of these to be set.

Example

Let's take a practical example; the admin group. Every time a player makes a channel, he is automatically added to the admin group. This doesn't automatically give him any privileges, it just marks him as a member of that group, however Murmur's default installation installs an ACL that gives the admin group write bit (all access).


In a structure like this:

  • Root
    • A
      • B
    • C
      • D

In Root, player "Big Boss" is alone in the admin group. In channel A, player "BossA" is in the Add list, and "BossB" is the same in channel B.

Since the admin group is inherited and inheritable, a player that is a member at any parent of the current channel is also a member in the current channel. So the total list of members in channel B is "Big Boss, BossA, BossB". The convenience of this system is that if we later att "Super Boss" to admin in Root, he'll automatically be in the admin group of every channel below.

Let's move on, and say that player "BossC" is in the Add list in channel C, but here admin is marked as not inherit. This means that "Big Boss" is not in the admin list, and any changes for admin in Root will not be seen here. Channel D will inherit the list from C, unless C also marks admin as not inheritable.

ACL

ACL (Access Control Lists) are all attached to a specific channel. A channel can specify if it wants to inherit the ACL on the parent, but it cannot specify which; it's a all or nothing deal. ACL are evaluated in order, from top to bottom along the chain of channels.

For each entry, either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. There are a few special groups defined:

all

Everyone

auth

All authenticated users

in

All users inside current channel

out

All users outside current channel

For each entry, permissions are either allowed or denied; in case of a conflict deny takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:

  • @all deny speak
  • @all allow speak

Then everyone will be allowed to speak. On the other hand

  • @all deny speak
  • @all allow traverse

Will deny speak from everyone.

Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both.

Write

This gives total control over the channel, including the ability to edit ACLs. This privilege implies all other privileges.

Traverse

Without this privlege, a player will be unable to access the channel or any subchannels in any way, regardless of privileges in the subchannel. Don't deny this unless you really know what you're doing; you can probably achieve the effect you want by denying a player the Enter privlege.

Enter

Allows player to enter channel. Even without this privilege, a player can be moved into the channel by a player with Move/Kick.

Speak

Allows player to speak in channel. For linked channels, only players with Speak privilege in the destination channels will be heard. This can be used to set up a hierarchy of linked channels where all players can hear all the leader of each group, but normal players will not be propageated outside their channel. This way, players will hear someone else is talkig to the group leader and (hopefully) stop talking for a short while.

If a player joins a channel he does not have Speak privilege in, he will be suppressed by the server, and will be unable to speak until someone unmutes him.

Mute / Deafen

Allows a player to mute or deafen another player. Note that mute status will follow a player until he is either manually unmuted or reconnects to the server.

Move / Kick

Allows a player to move another player to another channel or kick them off the server. Unless the target player has Enter privileges in the channel he's being moved to, Move privileges is required in both channels.

Make Channel

Allows a player to make a subchannel in the current channel. The player will automatically be added to the admin group in the new channel, so make the inheritable ACLs give the privileges you desire.

Link Channel

Allows a player to link or unlink, as well as push-to-link a channel. Unlinking requires Link privilege in either channel, and linking requires Link privilege in both.

= Examples

Group of servers with FPS game

In this example, we assume we have a group of public servers running FPS games. Each game has 2 competing sides, and each side consists of one or more squads. We want a hierarchy such as this:

  • Servers
    • "Servername"
      • Team 1
        • Squad 1
        • Squad 2
        • ...
      • Team 2
        • Squad 1
        • ...
      • ...
    • ...

Let's assume we have a small script linked with qstat that puts the player in the channel of the right side, and once in there we want to give them the ability to switch between squad channels and link at will. However, we do not want them to gain access to the channels of the other side.

This is actually a very straightforward implementation; on the "Servers" channel, define an empty group called players. Then, add the following acls:

  1. @all deny enter
  2. @players allow enter, allow link

The first rule denies enter privilege to all players. However, anyone in the players group will have the ability to enter and link. Have the script put players in the "players" group on the teams channel, and they'll be able to move at will between subchannels. Remember that unregistered players can't be a member of a group, so they're pretty much out of luck.

Actually, we might want to add a group binding called 'insubs', meaning a player is in either this channel or a subchannel; this would allow even unregistered players to move inside the small of team channel + squad channels.

MMORPG Raid

Assume this setup:

  • Root
    • Raid
      • Healers
      • Tanks
      • Damage Dealers
      • Wussards and other pets

The desire is to have one leader of each group, plus a few people as raid leaders.

Set this up as follows: In "Raid", create a group called "groupleaders". Put the leader of each group in this group. In the same channel define "raidleaders", and put the raidleaders in this group.

In the Raid channel, define the following ACLS:

  1. @all deny enter, deny speak [Apply Here only]
  2. @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]
  3. @groupleaders allow speak, allow link [Apply Here only]
  4. @groupleaders allow link, allow mute, allow kick [Apply Subs only]

The first rule makes sure nobody can speak or enter the Raid channel. The second rule lifts this restriction from anyone in the raidleaders group as well as giving them broad permissions. The third rule makes sure groupleaders can link and speak to the raid channel, and the fourth gives them permission to link from the subchannel as well as get rid of troublesome players.

Normal players will not be able to join the raid channel, but as that denial only applied in the raid channel they can join any subchannel they wish. When the channels are linked, everyone in the linked channels will hear raid leaders and group leaders. However, raid leaders will only hear group leaders, they will not hear normal players. This way, players can stay quiet when they hear a command coming down (and also hear the command direct without the groupleader having to repeat it), and if they don't that won't bother the rest of the raid.