Inconsistent privileges management via TCPQuery interface

[AMREG]

I use a test server (home-based, v2.0.20.1), and a "production" server (rented, v2.0.23.19).
Both run under Linux so I post here, but as it deals with the TCPQuery interface the following may apply as well to Windows TS2 servers (I simply have no way to check the Windows case).

I am preparing scripts to automate some users database updates, according to various criteria. So I'm focusing on what can be done using the TCPQuery interface.

1) Banning.

On both servers, my "ordinary" TS2 account has SA privileges (in other words, it is equivalent to the "admin" account, not to the "superadmin" one).

When I log in through a TS2 client with this account, I can ban or un-ban users from the server. OK, fine.
When I log in through the TCPQuery interface using the same account, I get "ERROR, invalid permissions" for exactly the same operations. Why ? (Yes, I first selected the correct server and logged in, prior to try to ban/unban... but no way).

To be able to (un)ban someone from the TCPQuery interface, I need to log in as superadmin, and only then it works. But what required SSA privileges via TCPQuery can always be undone via a simple SA-level login via the client. Seems inconsistent...

2) DBUserID.

Deleting a user from the database via the TCPQuery interface requires to provide his/her DBUserID. Normal so far.

What seems less normal is that the deletion itself only requires a SA-level login, but finding out the relevant DBUserID requires SSA-level login.
In other words, the "dbuserdel nnn" command needs only a SA-level login, but the "dbuserid" needed to get the "nnn" itself requires a SSA-level login (trying to issue a dbuserid with a simple SA-level login yields the same error as above - invalid permissions). Why ?

Note : Conversely, the related command "dbuserlist" only requires SA-level privileges, as could be expected. It produces the above DBUserID information (among a huge bunch of other information), so it seems definitely inconsistent to require the highest level login to be able to get the DBUserID only with "dbuserid", while it is available (with many other things) via a lower level login and "dbuserlist"...

So why do I not simply use the "dbuserlist" ? Just remember that all that stuff will eventually be done programatically. The "dbuserid" yields exactly what is needed (no more, no less), while extracting the same data from the output of "dbuserlist" both yields unneeded network traffic (especially on crowded servers) and requires developing additional software, simply to cope with what seems basically a unappropriate privilege management on the server's TCPQuery interface.

3) Other similar symptoms.

The same principle as above (SSA-level login abusively mandatory) applies to other commands on the interface, such as the "fp" command to find out the PlayerID of a connected player for subsequent actions.
For instance, the "kick p_id" (for kicking a connected user) only requires SA-level login, but finding out the necessary "p_id" using the "fp" command requires a SSA-level login (same old song...).
Similarly, the same "p_id" info can yet be obtained among many other things from a more general command ("pl"), here again with a simple SA-level login...

Sorry, I didn't test each and every command available with this interface, I tested only the ones I plan to use in the near future. But I ends with a general feeling of a systematically inconsistent privileges management...:(

[Peter]

Hey,

this is known. Best to use a SSA login when working with ts2 query. All will be better with TS3 though :)

[AMREG]

Hey,
this is known.
Sorry, I "RTFM" ;) and searched the forums for "tcpquery" and "login" but I didn't find out where it is mentioned. :o
Also, this is my very first thread in the TS forums, maybe I missed something. Mea culpa.
Anyway :

Best to use a SSA login when working with ts2 query.
Unfortunately, this is not always an option.

I fully own my test server, which means the Linux box is at my home, I run the physical server (i.e. the Linux process of the server), I own both the SA logins and the SSA login. So I have everything in my bare hands. :)

But this is a test server, just to help me develop my scripts.

The "production" server is only a virtual server on a physical server owned by others. In other words : I rent a TS service from others (a commercial company), they run a physical server with many other virtual servers besides mine. So getting a SSA login there is just impossible, at it would give me the full control on each and every virtual server they run, not only mine...:eek:
A major security flaw !!!

Unless they are completely insane, they would NEVER grant me that... And if they do, I would quickly run to look for other, less mad people to provide me the service... :D

I really appreciate you (= the team) are focusing on developing TS3, but I think there is a real need to allow administering a virtual server at a "virtual server level" login (i.e. SA-level, not SSA-level). Even on the TCPQuery interface.

Perhaps a possible workaround may be to directly issue SQL requests on the database server (either SQLite or MySQL, depending on their installation options) used by their physical TS server, but provided that :

they accept to provide my with the relevant parameters (type of database system, port to use, ...),
they accept to provide me an appropriate account on their database system, correctly "sanitized" to prevent me doing harm elsewhere... (Anyway I'm afraid this could only be possible with MySQL, not with SQLite).

Umhhhhh. I think I would embark in a long/hard negotiation in that case... ;)

[maxi1990]

Hey,

this is known. Best to use a SSA login when working with ts2 query. All will be better with TS3 though :)

I bolded the text that is most important about peter's answer. :)
You might have read that teamspeak2 will only be updated if major security flaws appear.

[Peter]

I agree with you that requiring SSA for more situtations than absolutly needed is a limiting and fundamentaly "wrong" way, but that's the way it is and as maxi pointed out, we are not going to change that for TS2. The query interface in TS2 also has the (in my opinion even worse) limitation that you can't do everything via it. Some features are just not possible via query...basically in TS2 you have:
- client (e.g. can do channel management)
- web interface (e.g. can do permissions management)
- query (e.g. can do timed bans)

All of the examples in brackets can *only* be done by this interface...so to use all features TS2 provides, you need to use 3 interfaces to "talk" with the server.

Compare this with TS3:
In TS3 the client and query interface are internally the same interface, so the query automatically and by definition can do everything a client can do (except listen/talk, voice data via query is ugly :p), and the web interface is not a separate interface at all anymore, but uses the query interface to do its job. Result is: There really is only one interface, no more code duplication, no more different features or behaviour. In short: good times ahead :)