Difference between revisions of "Talk:ACL and Groups/English"

From Mumble Wiki
Jump to: navigation, search
m (Talk:ACL and Groups moved to Talk:ACL and Groups/English)
 
Line 1: Line 1:
 
 
== The @sub group ==
 
== The @sub group ==
 
I'm having a hard time understanding the instructions given for the @sub group.
 
I'm having a hard time understanding the instructions given for the @sub group.
Line 6: Line 5:
 
It should also be made more clear which rules are inherited and which ones aren't.
 
It should also be made more clear which rules are inherited and which ones aren't.
 
It almost sounds as though this configuration isn't done through the ACL configuration in Mumble as I'm trying to do it, either that or it's an unusual way of explaining things. --[[User:Pilot 51|Pilot 51]] 08:21, 11 October 2007 (PDT)
 
It almost sounds as though this configuration isn't done through the ACL configuration in Mumble as I'm trying to do it, either that or it's an unusual way of explaining things. --[[User:Pilot 51|Pilot 51]] 08:21, 11 October 2007 (PDT)
 +
<br>
 +
<br>
 +
== How the most complex ACLs work ==
 +
Note: This section of discussion is to be used to improve and add to this information, which I have had sitting in a text file for about 8 months waiting for me to clean it up myself, to be posted on the main article in presentable form. --[[User:Pilot 51|Pilot 51]] 17:37, 9 August 2009 (UTC)<br>
 +
<br>
 +
=== Definitions ===
 +
The tilde (~) means the ACL is associated with the channel it is defined in rather than all channels it is inherited into. In other words, with the example, the user that the ACL applies to needs to be inside the defining channel (or defined channels if parameters are used) and not any of the channels that the ACL is inherited to. If the permission is set to allow write, the user is required to be in the defining channel in order to write to any of the channels that the ACL is inherited into.<br>
 +
<br>
 +
In the case of an ACL such as @~admin, it requires that the user is included in the group on the channel that the ACL is defined in to write to inheriting channels rather than included in the group for the channel that the user is trying to write to.<br>
 +
<br>
 +
When using ! (NOT / inverted) along with ~ for an ACL, ! must be before ~.<br>
 +
Example: @!~admin<br>
 +
<br>
 +
Example ACL: @~sub,-1,2,2 +write<br>
 +
Note: +write means write permission is allowed, it is not part of the ACL name.<br>
 +
<br>
 +
The first parameter (-1) defines the channel depth that the ACL applies to. In this case, it allows users in the parent channel to write to the defining channel and any of the inheriting channels.<br>
 +
<br>
 +
The second parameter (2) further defines the minimum channel depth that the ACL applies to. It is useful for allowing, for example, users in subchannels 2 deep from the parent channel to write to the defining channel and any of its subchannels.<br>
 +
<br>
 +
The third parameter (2) defines the maximum channel depth that the ACL applies to. If it is identical to the second parameter, the ACL only applies to a single specific depth.<br>
 +
<br>
 +
=== Examples ===
 +
'''Example channel layout'''<br>
 +
Root<br>
 +
-A<br>
 +
--A1<br>
 +
---Sub1<br>
 +
---Sub2<br>
 +
--A2<br>
 +
--A3<br>
 +
-B<br>
 +
--B1<br>
 +
--B2<br>
 +
<br>
 +
<br>
 +
'''Example 1'''<br>
 +
Root permissions: @all -write, inherited<br>
 +
A permissions: @in +write, inherited<br>
 +
Result: While in A or any of its subchannels, the user can only edit ACL for the channel he is in.<br>
 +
<br>
 +
'''Example 2'''<br>
 +
Root permissions: @all -write, inherited<br>
 +
A permissions: @~in +write, inherited<br>
 +
Result: While in A, the user can edit ACL for A and all its subchannels. While in any of the subchannels of A, the user cannot edit ACL for any of the channels.<br>
 +
<br>
 +
'''Example 3'''<br>
 +
Root permissions: @all -write, inherited<br>
 +
A permissions: @sub +write, inherited<br>
 +
Result: While in A, the user cannot edit ACL for any channels. While in any of the subchannels of A, the user can only edit ACL for parent channels up to A, but not the channel itself or child channels.<br>
 +
<br>
 +
'''Example 4'''<br>
 +
Root permissions: @all -write, inherited<br>
 +
A permissions: @~sub +write, inherited<br>
 +
Result: While in A, the user cannot edit ACL for any channels. While in any of the subchannels of A, the user can edit ACL for A and any of its subchannels.<br>
 +
<br>
 +
'''Example 5'''<br>
 +
Root permissions: @all -write, inherited<br>
 +
A permissions: @~sub,-1,2,2 +write, inherited<br>
 +
Result: While in A or Sub1, the user cannot edit ACL for any channels. While in A1, the user can edit ACL for A and any of its subchannels.<br>
 +
<br>
 +
'''Example 6'''<br>
 +
Root permissions: @all -write, inherited<br>
 +
A permissions: @~sub,0,2,2 +write, inherited<br>
 +
Result: While in A or A1, the user cannot edit ACL for any channels. While in Sub1, the user can edit ACL for A and any of its subchannels.<br>
 +
<br>
 +
'''Example 7'''<br>
 +
Root permissions: @all -write, inherited<br>
 +
A permissions: @~sub,-1,0 +write, inherited<br>
 +
Result: While in any of the subchannels of Root, but not Root itself, the user can edit ACL for A or any of its subchannels.<br>
 +
<br>
 +
'''Example 8'''<br>
 +
Root permissions: @all -write, inherited<br>
 +
A permissions: @~sub,0,2 +write, inherited<br>
 +
Result: While in Sub1 or Sub2, the user can edit ACL for A or any of its subchannels, but not while in any other channel.<br>
 +
<br>
 +
'''Example 9'''<br>
 +
Root permissions: @all -write, inherited<br>
 +
A permissions: @~sub,-1,2 +write, inherited<br>
 +
Result: While in any of the subchannels of A or B, but not A or B itself, the user can edit ACL for A or any of its subchannels.<br>

Latest revision as of 17:37, 9 August 2009

The @sub group

I'm having a hard time understanding the instructions given for the @sub group. Since the example given for [ACL_and_Groups#Group_of_servers_with_FPS_game|Group of servers with FPS game] is simple, I'll use that for my example why I'm confused. Am I supposed to rename the group from the default "~sub" to "~sub,2,2 allow enter, allow link", or "~sub,2,2" and then select allow for both Enter and Link permissions? What about the "+enter" and "+link" in the previous examples? I tried several things but I didn't see any results. Also what is the purpose of creating an empty group called "players" and then not creating an ACL for it? It should also be made more clear which rules are inherited and which ones aren't. It almost sounds as though this configuration isn't done through the ACL configuration in Mumble as I'm trying to do it, either that or it's an unusual way of explaining things. --Pilot 51 08:21, 11 October 2007 (PDT)

How the most complex ACLs work

Note: This section of discussion is to be used to improve and add to this information, which I have had sitting in a text file for about 8 months waiting for me to clean it up myself, to be posted on the main article in presentable form. --Pilot 51 17:37, 9 August 2009 (UTC)

Definitions

The tilde (~) means the ACL is associated with the channel it is defined in rather than all channels it is inherited into. In other words, with the example, the user that the ACL applies to needs to be inside the defining channel (or defined channels if parameters are used) and not any of the channels that the ACL is inherited to. If the permission is set to allow write, the user is required to be in the defining channel in order to write to any of the channels that the ACL is inherited into.

In the case of an ACL such as @~admin, it requires that the user is included in the group on the channel that the ACL is defined in to write to inheriting channels rather than included in the group for the channel that the user is trying to write to.

When using ! (NOT / inverted) along with ~ for an ACL, ! must be before ~.
Example: @!~admin

Example ACL: @~sub,-1,2,2 +write
Note: +write means write permission is allowed, it is not part of the ACL name.

The first parameter (-1) defines the channel depth that the ACL applies to. In this case, it allows users in the parent channel to write to the defining channel and any of the inheriting channels.

The second parameter (2) further defines the minimum channel depth that the ACL applies to. It is useful for allowing, for example, users in subchannels 2 deep from the parent channel to write to the defining channel and any of its subchannels.

The third parameter (2) defines the maximum channel depth that the ACL applies to. If it is identical to the second parameter, the ACL only applies to a single specific depth.

Examples

Example channel layout
Root
-A
--A1
---Sub1
---Sub2
--A2
--A3
-B
--B1
--B2


Example 1
Root permissions: @all -write, inherited
A permissions: @in +write, inherited
Result: While in A or any of its subchannels, the user can only edit ACL for the channel he is in.

Example 2
Root permissions: @all -write, inherited
A permissions: @~in +write, inherited
Result: While in A, the user can edit ACL for A and all its subchannels. While in any of the subchannels of A, the user cannot edit ACL for any of the channels.

Example 3
Root permissions: @all -write, inherited
A permissions: @sub +write, inherited
Result: While in A, the user cannot edit ACL for any channels. While in any of the subchannels of A, the user can only edit ACL for parent channels up to A, but not the channel itself or child channels.

Example 4
Root permissions: @all -write, inherited
A permissions: @~sub +write, inherited
Result: While in A, the user cannot edit ACL for any channels. While in any of the subchannels of A, the user can edit ACL for A and any of its subchannels.

Example 5
Root permissions: @all -write, inherited
A permissions: @~sub,-1,2,2 +write, inherited
Result: While in A or Sub1, the user cannot edit ACL for any channels. While in A1, the user can edit ACL for A and any of its subchannels.

Example 6
Root permissions: @all -write, inherited
A permissions: @~sub,0,2,2 +write, inherited
Result: While in A or A1, the user cannot edit ACL for any channels. While in Sub1, the user can edit ACL for A and any of its subchannels.

Example 7
Root permissions: @all -write, inherited
A permissions: @~sub,-1,0 +write, inherited
Result: While in any of the subchannels of Root, but not Root itself, the user can edit ACL for A or any of its subchannels.

Example 8
Root permissions: @all -write, inherited
A permissions: @~sub,0,2 +write, inherited
Result: While in Sub1 or Sub2, the user can edit ACL for A or any of its subchannels, but not while in any other channel.

Example 9
Root permissions: @all -write, inherited
A permissions: @~sub,-1,2 +write, inherited
Result: While in any of the subchannels of A or B, but not A or B itself, the user can edit ACL for A or any of its subchannels.