Information Permission assignment process

[WolverinDEV]

Hey,
as lately significantly the question rises how the permission system works, as well to exactly determine bugs when it does not work,
here is/are some flow charts which should outline of it works.

Adding/modifying permissions of a Group/Channel/Client/Playlist

​

List of permissions which are not limited by the permission modify power:

Spoiler: Ignored permissions

i_icon_id
i_max_icon_filesize
i_client_max_avatar_filesize
i_ft_quota_mb_download_per_client
i_ft_quota_mb_upload_per_client

i_client_max_channels
i_client_max_permanent_channels
i_client_max_semi_channels
i_client_max_temporary_channels
i_channel_create_modify_with_temp_delete_delay
i_client_talk_power
i_client_needed_talk_power
b_channel_create_with_needed_talk_power

i_channel_max_depth
i_channel_min_depth
i_client_max_channel_subscriptions

i_client_music_create_modify_max_volume
i_max_playlist_size
i_max_playlists

i_client_poke_max_clients

i_client_ban_max_bantime
i_client_max_idletime
i_group_sort_id

Notices:
- This flow chat applied to all TeaSpeak - Server versions above 1.4.14b5.
- Permission assignment for playlists/client playlist permissions have been adjusted like that in 1.4.14b6.

 

[eduardoroeder]

Hey @WolverinDEV, thanks for the complete answer! It took some time to ellaborate my question and I'm glad to see you spent quite some time to ellaborate a decent answer aswell When our feedback is being received like that, It motivates people reporting more and more bugs

I've been with no computer access for the last three days so I couldn't actually answer and try out the versions, that's why I didn't reply yet to anything.

Anyways, since you guys already closed the topic I created (3 days ago, closing so fast...), I'll answer you here and hope to follow up here, alright?

The chart looks really promising, I know it is hard to do logical workflows like that, but it actually aids everybody to see it clearer, mainly for the developer itself (sometime our IF/ELSE/FOR/WHILE might get quite confusing haha).

So, there is two points I'd like to point out on the chart, and want to have a feedback on it:

1. Where does the "ignored permissions" apply on the chart/loop? Like the icon_id, avatar_max_size, i_channel_create_modify_with_temp_delete_delay or any others that should accept more than 100 values and have custom parsing?
2. It actually boils down to every permission needing GRANTED at least 1, isn't it? After all those checks, to leave the "permission set loop", it actually checks if granted is bigger than 1, which was the main concern about my post. This makes the need to all already created Server Admin (and their splitted subsidiaries that the clients may have created) have granted on their allowed permission change, isn't it?

Well, it really seems a quite delicated structure of checks, specially when involving the core of the server.

Thanks



------------- Edit
Since I've written this, the other thread seems to be reopened and then closed again. In the meantime I was writing a review and recording how to reproduce, since the 1.4.14 b5 didn't fix any of those. I'll just paste it here what I answered there (but failed to effectively send the answer because the thread has been closed since).

--------------

It still needs the user to have the GRANT permission to actually apply the channel specified permission. I've updated to the latest beta5 and the first thing I did was to reproduce the steps I explained in OP, and the testing shows the same thing as the Diagram: you need to have GRANT on the target permission before assigning. Why would you need grant in a "needed_power" permission? I've tryied with more than 3 situations, but I'll stick with the one I did with OP, for the reason of you guys reproduce.

Right.

Take a look how to reproduce it. All changes were made within the YaTQA, the TS3 client is an example (had it set up for recording already).

http://imgur.com/QIe37IE

I'd suggest that if you have "b_permission_modify_ignore_power", it jumps out the granted check, since it should ignore any NEEDED permission (grant permissions are NEEDED permission).

 

[WolverinDEV]

> Anyways, since you guys already closed the topic I created (3 days ago, closing so fast...), I'll answer you here and hope to follow up here, alright?
Yes all right We thought it has been resolved

Charts questions:
1) Its the first step "Check if permission required power".
I not updated the thread so I list these permission as well.
2) By default Server Admin has on all (which are not instance permissions) permissions a granted power of at least 1.
This should not be an issue.

The i_needed_power_.... are the granted permissions
Their value is the granted value for the permission.

Yes the jump from b_permission_modify_ignore_power sounds plausible.
Will be implemented in 1.4.14b6

 

[eduardoroeder]

Thanks for the reply!

For point 1 that's better for undestanding, nice addition

For point 2, well default Server Admins are the ones that's created from template... For new instances. And how does that back propagate to already created and modified Server Admins?

The b_permission_modify_ignore_power jump addition is also a nice approach, I'm pretty sure.
Thanks for the support.

Ans last, I was trying out on how this works in TS3, and actually found that the "grant" check only came into play if any of the groups for that virtual server has "grant" for that specified permissions, otherwise just the regular permissions check apply. This could be a better solution aswell.

 

[WolverinDEV]

> For point 2, well default Server Admins are the ones that's created from template... For new instances. And how does that back propagate to already created and modified Server Admins?

There is no need, by default regardless of the software ServerAdmin has the proper granted (i_needed_power_....) permissions.

TS3 uses i_needed_power_... as grant permissions since the permissions itself have no "grant" value.
But the i_needed_power_... permissions have no effect at all except holding a new value to i merged them directly within the internals of TeaSpeak.

---- Automatically Merged Double Post ----

Adjusted the flow chart to fit 1.4.14-beta6

 

[REDOSS]

Since this topic is noted as informative and contains quite useful information about the work of the permission system.
I will leave this link in this topic, since this is the topic that started the entire discussion.