Pending i_permission_modify_power error in different situations

[eduardoroeder]

Hey, this started happening after the 1.4.14 update, which happened changes to the permission system. I've created this thread in order to address overheads that started to happen after this update. It is really important and urgent since it affects all created groups and how they behave. Alright, I'll try to cover up those situations and try to be very direct aswell, in order to keep things tidy. I hope this gets the proper attention.

Before anything, let me clarify some terms. When I say Server Manager, I mean WE, that provide virtual instances to potential customers. When I say Server Admin, I mean the customer (or his friends that uses and administrate one instance for the long run) or the Server Group called Server Admin (in which that customer belongs) which has enough permissions to edit almost everything (up to their correspondent grant power, if present) but doesn't have all the permissions setted (for example, there is no need for a group have i_channel_needed_modify_power or i_channel_needed_delete_power permissions). Also, I'm using the TS3 client just in order to show a common use scenario, but I've replicated with a TeaClient aswell. It is just that the TS3 client looks more tidy at the moment.

This is what the Server Admin group has from permissions:

Spoiler: permission list

b_virtualserver_info_view 1 0 0 75
b_virtualserver_connectioninfo_view 1 0 0 75
b_virtualserver_channel_list 1 0 0 75
b_virtualserver_channel_search 1 0 0 75
b_virtualserver_client_list 1 0 0 75
b_virtualserver_client_search 1 0 0 75
b_virtualserver_client_dblist 1 0 0 75
b_virtualserver_client_dbsearch 1 0 0 75
b_virtualserver_client_dbinfo 1 0 0 75
b_virtualserver_permission_find 1 0 0 75
b_virtualserver_custom_search 1 0 0 75
b_virtualserver_token_list 1 0 0 75
b_virtualserver_token_add 1 0 0 75
b_virtualserver_token_use 1 0 0 75
b_virtualserver_token_delete 1 0 0 75
b_virtualserver_log_view 1 0 0 75
b_virtualserver_log_add 1 0 0 75
b_virtualserver_join_ignore_password 1 0 0 75
b_virtualserver_notify_register 1 0 0 75
b_virtualserver_notify_unregister 1 0 0 75
b_virtualserver_modify_name 1 0 0 75
b_virtualserver_modify_welcomemessage 1 0 0 75
b_virtualserver_modify_reserved_slots 1 0 0 75
b_virtualserver_modify_password 1 0 0 75
b_virtualserver_modify_default_servergroup 1 0 0 75
b_virtualserver_modify_default_channelgroup 1 0 0 75
b_virtualserver_modify_default_channeladmingroup 1 0 0 75
b_virtualserver_modify_channel_forced_silence 1 0 0 75
b_virtualserver_modify_complain 1 0 0 75
b_virtualserver_modify_antiflood 1 0 0 75
b_virtualserver_modify_ft_settings 1 0 0 75
b_virtualserver_modify_ft_quotas 1 0 0 75
b_virtualserver_modify_hostmessage 1 0 0 75
b_virtualserver_modify_hostbanner 1 0 0 75
b_virtualserver_modify_hostbutton 1 0 0 75
b_virtualserver_modify_needed_identity_security_level 1 0 0 75
b_virtualserver_modify_priority_speaker_dimm_modificator 1 0 0 75
b_virtualserver_modify_min_client_version 1 0 0 75
b_virtualserver_modify_icon_id 1 0 0 75
b_virtualserver_modify_codec_encryption_mode 1 0 0 75
b_virtualserver_modify_temporary_passwords 1 0 0 75
b_virtualserver_modify_channel_temp_delete_delay_default 1 0 0 75
i_channel_max_depth 10 0 0 75
i_channel_permission_modify_power 75 0 0 75
b_channel_info_view 1 0 0 75
b_virtualserver_channel_permission_list 1 0 0 75
b_channel_create_child 1 0 0 75
b_channel_create_permanent 1 0 0 75
b_channel_create_semi_permanent 1 0 0 75
b_channel_create_temporary 1 0 0 75
b_channel_create_private 1 0 0 75
b_channel_create_with_topic 1 0 0 75
b_channel_create_with_description 1 0 0 75
b_channel_create_with_password 1 0 0 75
b_channel_create_modify_with_codec_speex8 1 0 0 75
b_channel_create_modify_with_codec_speex16 1 0 0 75
b_channel_create_modify_with_codec_speex32 1 0 0 75
b_channel_create_modify_with_codec_celtmono48 1 0 0 75
b_channel_create_modify_with_codec_opusvoice 1 0 0 75
b_channel_create_modify_with_codec_opusmusic 1 0 0 75
i_channel_create_modify_with_codec_maxquality 10 0 0 75
i_channel_create_modify_with_codec_latency_factor_min 1 0 0 75
b_channel_create_with_maxclients 1 0 0 75
b_channel_create_with_maxfamilyclients 1 0 0 75
b_channel_create_with_sortorder 1 0 0 75
b_channel_create_with_default 1 0 0 75
b_channel_create_with_needed_talk_power 1 0 0 75
b_channel_create_modify_with_force_password 1 0 0 75
i_channel_create_modify_with_temp_delete_delay 86400 0 0 75
b_channel_modify_parent 1 0 0 75
b_channel_modify_make_default 1 0 0 75
b_channel_modify_make_permanent 1 0 0 75
b_channel_modify_make_semi_permanent 1 0 0 75
b_channel_modify_make_temporary 1 0 0 75
b_channel_modify_name 1 0 0 75
b_channel_modify_topic 1 0 0 75
b_channel_modify_description 1 0 0 75
b_channel_modify_password 1 0 0 75
b_channel_modify_codec 1 0 0 75
b_channel_modify_codec_quality 1 0 0 75
b_channel_modify_codec_latency_factor 1 0 0 75
b_channel_modify_maxclients 1 0 0 75
b_channel_modify_maxfamilyclients 1 0 0 75
b_channel_modify_sortorder 1 0 0 75
b_channel_modify_needed_talk_power 1 0 0 75
i_channel_modify_power 75 0 0 75
b_channel_modify_make_codec_encrypted 1 0 0 75
b_channel_modify_temp_delete_delay 1 0 0 75
b_channel_delete_permanent 1 0 0 75
b_channel_delete_semi_permanent 1 0 0 75
b_channel_delete_temporary 1 0 0 75
b_channel_delete_flag_force 1 0 0 75
i_channel_delete_power 75 0 0 75
b_channel_join_permanent 1 0 0 75
b_channel_join_semi_permanent 1 0 0 75
b_channel_join_temporary 1 0 0 75
b_channel_join_ignore_password 1 0 0 75
b_channel_join_ignore_maxclients 1 0 0 75
i_channel_join_power 80 0 0 75
i_channel_view_power 75 0 0 75
i_channel_subscribe_power 80 0 0 75
i_channel_description_view_power 80 0 0 75
i_max_icon_filesize 100000 0 0 75
b_icon_manage 1 0 0 75
b_group_is_permanent 1 0 0
i_group_auto_update_type 45 0 0 75
i_group_auto_update_max_value 45 0 0 75
i_group_sort_id 105 0 0
b_virtualserver_servergroup_list 1 0 0 75
b_virtualserver_servergroup_permission_list 1 0 0 75
b_virtualserver_servergroup_client_list 1 0 0 75
b_virtualserver_channelgroup_list 1 0 0 75
b_virtualserver_channelgroup_permission_list 1 0 0 75
b_virtualserver_channelgroup_client_list 1 0 0 75
b_virtualserver_servergroup_create 1 0 0 75
b_virtualserver_channelgroup_create 1 0 0 75
i_server_group_modify_power 75 0 0 75
i_server_group_needed_modify_power 75 0 0 75
i_server_group_member_add_power 75 0 0 75
i_server_group_needed_member_add_power 75 0 0 75
i_server_group_member_remove_power 75 0 0 75
i_server_group_needed_member_remove_power 75 0 0 75
i_group_member_add_power 75 0 0 75
i_group_needed_member_add_power 75 0 0 75
i_group_member_remove_power 75 0 0 75
i_group_needed_member_remove_power 75 0 0 75
i_group_modify_power 75 0 0 75
i_group_needed_modify_power 75 0 0 75
i_permission_modify_power 75 0 0 75
b_permission_modify_power_ignore 1 0 0 75
b_virtualserver_servergroup_delete 1 0 0 75
b_virtualserver_channelgroup_delete 1 0 0 75
i_client_permission_modify_power 75 0 0 75
i_client_needed_permission_modify_power 75 0 0 75
i_client_max_clones_uid 10 0 0 75
i_client_max_channel_subscriptions -1 0 0 75
b_client_ignore_bans 1 0 0 75
b_client_ignore_antiflood 1 0 0 75
b_client_issue_client_query_command 1 0 0 75
b_client_use_reserved_slot 1 0 0 75
b_client_use_channel_commander 1 0 0 75
b_client_request_talker 1 0 0 75
b_client_avatar_delete_other 1 0 0 75
b_client_ignore_sticky 1 0 0 75
b_client__music_create_permanent 1 0 0 75
b_client__music_create_semi_permanent 1 0 0 75
b_client__music_create_temporary 1 0 0 75
b_client__music_modify_permanent 1 0 0 75
b_client__music_modify_semi_permanent 1 0 0 75
b_client__music_modify_temporary 1 0 0 75
i_client__music_create_modify_max_volume 75 0 0 75
b_client_info_view 1 0 0 75
b_client_permissionoverview_view 1 0 0 75
b_client_permissionoverview_own 1 0 0 75
b_client_remoteaddress_view 1 0 0 75
i_client_serverquery_view_power 75 0 0 75
i_client_needed_serverquery_view_power 75 0 0 75
b_client_custom_info_view 1 0 0 75
b_virtualserver_channelclient_permission_list 1 0 0 75
b_virtualserver_client_permission_list 1 0 0 75
i_client_kick_from_server_power 75 0 0 75
i_client_needed_kick_from_server_power 75 0 0 75
i_client_kick_from_channel_power 75 0 0 75
i_client_needed_kick_from_channel_power 75 0 0 75
i_client_ban_power 80 0 0 75
i_client_needed_ban_power 80 0 0 75
i_client_move_power 75 0 0 75
i_client_needed_move_power 75 0 0 75
i_client_complain_power 75 0 0 75
i_client_needed_complain_power 75 0 0 75
b_client_complain_list 1 0 0 75
b_client_complain_delete_own 1 0 0 75
b_client_complain_delete 1 0 0 75
b_client_ban_list 1 0 0 75
b_client_ban_create 1 0 0 75
b_client_ban_delete_own 1 0 0 75
b_client_ban_delete 1 0 0 75
i_client_ban_max_bantime -1 0 0 75
i_client_private_textmessage_power 75 0 0 75
b_client_server_textmessage_send 1 0 0 75
b_client_channel_textmessage_send 1 0 0 75
b_client_offline_textmessage_send 1 0 0 75
i_client_talk_power 81 0 0 75
i_client_poke_power 75 0 0 75
i_client_needed_poke_power 25 0 0 75
b_client_set_flag_talker 1 0 0 75
b_client_modify_description 1 0 0 75
b_client_modify_own_description 1 0 0 75
b_client_use_bbcode_any 1 0 0 75
b_client_use_bbcode_url 1 0 0 75
b_client_use_bbcode_image 1 0 0 75
b_client_delete_dbproperties 1 0 0 75
b_client_create_modify_serverquery_login 1 0 0 75
b_ft_ignore_password 1 0 0 75
i_ft_file_upload_power 75 0 0 75
i_ft_file_download_power 75 0 0 75
i_ft_file_delete_power 75 0 0 75
i_ft_file_rename_power 75 0 0 75
i_ft_file_browse_power 75 0 0 75
i_ft_directory_create_power 75 0 0 75
i_ft_quota_mb_download_per_client 1000 0 0 75
i_ft_quota_mb_upload_per_client 1000 0 0 75

Let's get to it.

One scenario that this is happening is when editing a channel. The server admin can edit the channel information (title and such) but he cannot set any of the properties/permissions:

http://imgur.com/nehL3mo

http://imgur.com/OdkTucw

Notice the i_channel_needed_modify_power inside the channel set to 70 and i_channel_modify_power in the client is set to 75 (with grant 75 aswell). Yet it gives me the error of insuficient client permissions (i_permission_modify_power)

http://imgur.com/KkOQMkZ

This happens because the i_channel_needed_modify_power permission is looking for the respective grant permission, which Server Admin has not (why the hell would a group need this permission set? even for the grant), thus inehiriting from the channel a default of 0 grant permission

Sum of the client permissions:
    i_channel_modify_power 75 0 0 75
    i_channel_needed_modify_power 70 0 0

If I set to that channel (with serverquery admin) a grant value to that permission, I'm able to change it via the client interface. So, the problem is in the grant check.

Other scenario that this is happening is with permissions with no grant powers. Since now it is obligated to have "grant permission" set, you're not able to set a grant permission to any group If my group doesn't have the respective grant anymore, making we as Server Manager to update every other Server Admin group we potentially had before this update. Its completely unviable, because since we (I believe we all offer) offer a sample Server Admin group, each customer may change that group to other permissions, split it into smaller others or even delete it. This maintenance is going to be manual. Personaly, I can handle it, but its unmaintainable... Because you wont set granted to all the groups existing in each server (this would be a security risk since it might allow some permissions to be changed) and will be a increasing demand on "fix permission support" from those Server Admin to the Server Managers.

I've experienced an issue sometimes with the permissions that are able to set bigger than 100, but couldn't reproduce to explain here in this thread.

In my opinion, forcing every manager group to have grant permisson is a shoot in your foot, because this will double the efforts needed when one is managing multiple servers. You have to make sure that every *_NEEDED_* permission and every GRANTED for that permission is not overhided by any other setup, which makes inviable for the common Server Admin to manage servers with 150+ groups, with 5-10 tiers of hierarchy. What do you guys think about it? If you got this far is because you acatually read the thread and since we all are in the same boat, it would be good to hear other Server Manager and see If I am missing something or if there is a better way that @WolverinDEV could handle the situation.

 

[Vafin]

This is why I test new versions of the server on a test server and update the main servers only when I am sure of it.

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

My opinion is that the main permissions should be as close as possible to the TS3 permissions, since users may have problems when configuring the server.

 

[REDOSS]

Yes, I really don't understand why the "Grant" check is performed in this case, but when the "i_channel_needed_modify_power" permission is missing, the check is also performed for this case. I think this is a bug.

But in any case, it's worth waiting for Markus to respond.

 

[WolverinDEV]

Hey,
thanks for your effort.
I think the whole thing boils down to a simple but crucial mistake.

I (currently) take the max permission value from i_permission_modify_power.
But instead of using the value I used the granted value, which is literally just a boolean which is flipped wrongly.

So in general how the permission system checks (and should check in the next update) for permissions:


Okey, I've to study now.
I'll release a new server version this evening, using the actual value and not the granted value.

 

[REDOSS]

@eduardoroeder try 1.4.14-beta-5

 

[WolverinDEV]

Any feedback?

 

[mkll11one]

Any feedback?

I did a test, as "Server Admin" and I got no error with editing: 1000 or 10000 no error =)

 

[WolverinDEV]

So but only for I_icon_id, not for i_permission_modify_power?
So it works like described in the chart above correctly?

 

[mkll11one]

So but only for I_icon_id, not for i_permission_modify_power?
So it works like described in the chart above correctly?

If I change i_permission_modify_power to 100 = work. but it will "denied" if I try 101 or 1000 =)

 

[WolverinDEV]

Perfectly so I'll close this one here. But I have to save that chart somewhere

 

[eduardoroeder]

Not fixed. Like I explained in the "Permission Assignmet Process" (I'll c&p that response here)

Spoiler: Message

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:

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?
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

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).

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

Also, I was just trying out on how this works in TS3, and 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.

@WolverinDEV

 

[alisb]

i have a this problem too
i cannt change i_permission_modify_power
and i cannt turn off or on this permissions "b_client_skip_channelgroup_permissions"

@WolverinDEV

 

[WolverinDEV]

By default you should.
Either TeaSpeak and TS3 servewr admins have a granted permission of at least 1 for all permissions which they should be capable to modifying.
This also includes (b_client_skip_channelgroup_permissions.
Default TS3 server configuration:

TeaSpeak has the same permission setup

 

[REDOSS]

// Closed && fixed.