This file is indexed.

/etc/armagetronad/settings_authentication.cfg is in armagetronad-common 0.2.8.3.4-1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
#########################################################################
# IMPORTANT: Users should NOT edit this file. Instead, copy the
#            lines you want to change into a new file named autoexec.cfg
#            ( either here or in your var directory ).
#            This file will be overwritten when you upgrade, autoexec.cfg won't.
#            Be sure to save the file as plain text, not rich text, especially
#            if you're using TextEdit on a Mac.
#########################################################################

#########################################################################
#
# Policies
#
#########################################################################

# As all Armagetron subsystems, Authentication is complex and has many
# options for you to tweak. The policies for the default settings were
# chosen with the following priorities:
# 1. Compatibility with old clients
# 2. Security
# 3. General usability
# If you are a very security aware person, you will probably disagree
# with the priority choilce of 1. vs 2, and want to get maximal security,
# even if that means old clients will not be able to authenticate on
# your server; in this case, uncomment the following line:

# HASH_METHOD_BLACKLIST bmd5

# this will disable the hash protocol clients up to 0.2.8.2.1 knew as
# the only one, which is vulnerable to relatively easy man in the
# middle attacks. New clients will, by default, refuse to use it, so
# if the the admins on your server are well educated and protect their
# login data with all means available to them, which includes using an
# up-to-date client, you should be safe even without this setting.
# You may get the occasional faked login from a regular player, though.

#########################################################################
#
# Local Accounts
#
#########################################################################

# To help your local users store their passwords, you should change the
# following settings to something server-specific:

MD5_PREFIX %u:
MD5_SUFFIX :arma

# those are strings that are appended/prepended to the password before
# the hash function is applied to them. So far, only the md5 protocol
# supports them, bmd5 ignores them. If you put a %u into the strings,
# it will be replaced by the username. This helps combat precomputation
# attacks; for team accounts, it will force the password to be kept in
# memory in plain text, though (not much of a problem).
# You need to set these up before you define the accounts.

# The following commands are available for you to create local accounts:

# LOCAL_USER <user name> <user password>

# Creates an account for a single player. You should restrict the username
# to ASCII characters, best lowercase letters and numbers, and avoid spaces
# and the symbols @, #, \, :, and %. They will still work, but look ugly
# in the logs and on the screen because they all need to get escaped.
# Spaces in the username, if you absolutely must have them, need to
# be quoted or escaped, the user "Foo Bar" can get an account with either
# LOCAL_USER "Foo Bar" <password>
# or
# LOCAL_USER Foo\ Bar <password>
# You can get a literal \ into a usename by putting it there twice.

# When logged in, local user accounts will appear as <user name>@ in the logs
# and on the screen, and they will have "Local" access rights by default.

# You can also define accounts for whole teams with

# LOCAL_TEAM <team name> <team password>

# Those accouts will allow login from all usernames with a name starting with
# the team name. Users logged in via such an account will appear as
# <user name>@L_TEAM and get the access rights of "Team Member", more
# about that later. Accounts of this type are intended to be used for organized
# tournaments.

# You can remove both kinds of accounts with USER_REMOVE.

#########################################################################
#
# Remote Accounts
#
#########################################################################

# We support a distributed authentication system where a user has to only get
# an account at the authority of his choice and use that to authenticate with
# on all participating servers. By default, this system is disabled. Enable
# it by changing the following setting to 1.

GLOBAL_ID 0

# Your server will then make connection to the remote authentication servers
# every time a user will try to authenticate; those connections will happen
# in the background and should not cause too much extra lag.

# Accounts from remote authentication servers will appear as
# <user name>@<authority> in your logs.

# Maybe you don't want to accept logins from all authorities. If you want to
# exclude some, put them into this comma separated list:

AUTHORITY_BLACKLIST

# If you only want to accept logins from a selected group of authorities, put
# them into this comma separated list:

AUTHORITY_WHITELIST

#########################################################################
#
# Access Rights
#
#########################################################################

# The old, single password inteface to the /admin command is disabled
# when you compile a server with this authentication. Instead, you
# can assign access rights to individual players with

# USER_LEVEL <user name> <level>

# The user name is the user's full authentication name as it appears in
# your logs, with all the escapes and character encodings; the "Foo Bar@"
# user from the example above would usually appear as Foo\_Bar@, and that
# is how you need to put him there. The level is the numberic access level;
# lower values are better. The predefined meanings (of course, you can
# disagree and define your own) of these are:

# Level  Meaning        Details
# 0      Owner          The owner of the server. Commands entered on the
#                       server console are executed with these rights.
# 1      Admin          A server administrator. By default, almost as
#                       powerful as the owner himself.
# 2      Moderator      A server moderator. Is still allowed to use /admin,
#                       but is restricted to player management commands.
# 7      Team Leader    Leader of a team. By default, no admin rights at all.
# 8      Team Member    Member of a team. Local team accounts get this level.
# 12     Local User     Players with local accounts get this level.
# 15     Remote User    Players with remote accounts get this level by default.
# 16 Fallen from Grace  Authenticated players who abused default rights given
#                       to them.
# 17     Shunned        Same, only worse :)
# 19     Authenticated  Minimal level authenticated players can get.
# 20     Program        Unauthenticated players.

# As you see, lower numeric values mean more access rights. When we say
# "a user needs at least level X to do Y", that means his numeric level
# needs to be smaller or equal than X.

# Remote (Global ID) accounts run a slightly higher risk of getting
# compromised than local accounts (simpy due to the fact that they
# will get used more often in more locations), so you should restrict
# Admin and Moderator rights to local accounts. To still have your
# Admins and Moderators appear with their Global ID accounts in your
# logs, use this little trick: define them a local account, give
# the rights to that, and define an alias for the local account:

# LOCAL_USER z-man <password>
# USER_LEVEL z-man@ 1
# USER_ALIAS z-man@ Z-Man@forums

# When your admin then logs in to your server under his global account,
# nothing special happens; only when he uses your local account, he
# will get the access rights, and apart from that, there will be no
# differences; he still wil appear under his global account.

# You can modifiy the minimal access rights required to do certain things.
# First, there are the administrative chat commands. To use /admin, you
# need to be at least

ACCESS_LEVEL_ADMIN 2

# To use the /teach or /rtfm command you need at least

ACCESS_LEVEL_RTFM 2

# To use the /op and /deop ad-hoc access level modifying
# commands, you need ot have at least

ACCESS_LEVEL_OP 7

# and that command cannot directly raise the level of a user above

ACCESS_LEVEL_OP_MAX 2

# (and of course, not above the player issuing these commands.)

# To manage teams with the /lock, /unlock, /invite and /univite commands
# in all circumstances, you need this access level:

ACCESS_LEVEL_TEAM 7

# As an emergency feature, /unlock and /invite are also always available
# to the players with the highest access level of a team.

# To play on the server, you need to be at least at

ACCESS_LEVEL_PLAY 20

# However, if at leat

ACCESS_LEVEL_PLAY_SLIDERS 4

# users of a higher access level than you want to play, and
# your level is below

ACCESS_LEVEL_PLAY_SLIDING 20

# you still will not be able to play. This is for servers with
# flexible tournament schedules, there you'll want to raise
# it to the level of 8 (Team Member), so that once some members
# of teams authorized to play on your server log in, all other
# players get removed.

# To be able to chat, you need at least this level:

ACCESS_LEVEL_CHAT 20

# If you don't have that, everyone on the server will be reminded
# that you want to chat at most every

ACCESS_LEVEL_CHAT_TIMEOUT 60

# seconds.

# If you are spectating a game and your access level is at least

ACCESS_LEVEL_SPY_TEAM 2

#, you will see all /team messages. And if your level is at least

ACCESS_LEVEL_SPY_MSG 0

# (no need to be a spectator), you will also see the /msg messages.

# Another change when compiling with armathication is that the old
# setting TEAM_ALLOW_SHUFFLE_UP is replaced by an access level
# that's required to shuffle up. This defaults to team members.

ACCESS_LEVEL_SHUFFLE_UP 8

# Issuing each vote type also requires a certain access level. By
# default (for unchanged behavior relative to previous versions),
# kick and suspend votes are available for everyone.

ACCESS_LEVEL_VOTE_REMOVE 20
ACCESS_LEVEL_VOTE_KICK 20
ACCESS_LEVEL_VOTE_INCLUDE 2
ACCESS_LEVEL_VOTE_COMMAND 2

# direct command votes will be executed at the access level of the
# vote submitter (usage example: poll for SCORE_HOLE in a tournament
# game), or, if that is higher, the following access level.

ACCESS_LEVEL_VOTE_INCLUDE_EXECUTE 2
ACCESS_LEVEL_VOTE_COMMAND_EXECUTE 2

# Having sufficient rights to use /admin does not entitle you to
# use all of the commands; they need to be unlocked for you.
# By default, most Admins can use all commands. To change the
# access level required to use a command, use

# ACCESS_LEVEL <command> <level>

# That command itself is by default restricted to be used by
# the owner, because it is the master key to all other commands.

# Sensible commands to unlock for moderator use are (this is the default):

ACCESS_LEVEL PLAYER_MESSAGE 2
ACCESS_LEVEL KICK 2
ACCESS_LEVEL BAN 2
ACCESS_LEVEL KICK_TO 2
ACCESS_LEVEL MOVE_TO 2
ACCESS_LEVEL SUSPEND 2
ACCESS_LEVEL UNSUSPEND 2
ACCESS_LEVEL KILL 2
ACCESS_LEVEL SILENCE 2
ACCESS_LEVEL VOICE 2
ACCESS_LEVEL ALLOW_RENAME_PLAYER 2
ACCESS_LEVEL DISALLOW_RENAME_PLAYER 2
ACCESS_LEVEL RENAME 2
ACCESS_LEVEL CONSOLE_MESSAGE 2
ACCESS_LEVEL CENTER_MESSAGE 2

# If you want to give team members access to the basic /admin command,
# you can also allow them to manage players:

ACCESS_LEVEL ALLOW_TEAM_CHANGE_PLAYER 7
ACCESS_LEVEL DISALLOW_TEAM_CHANGE_PLAYER 7

# A very powerful command with access levels is CASACL, prounounced
# like Quetzalcoatl, your friendly Aztec God. A bit like the suid flag
# on Unix executables, the setuid system command, and not completely
# unlike the sudo shell command or, if you go very far, Access Control
# in Vista, it allows to change the access level a config file is
# executed under. If you put

# CASACL <required access level> <elevated access level>

# into a configuration file, and a remote admin with at least the rights
# <required access level> orders to include that file, the commands after
# the CASACL command will be executed as if the user had access level
# <elevated access level>. Otherwise, script execution is aborted.
# The effect carries on to other config files included by the one with
# the CASACL command, but wears off as soon as processing the file with
# the command is done. Especially, since every command given as remote
# admin directly is considered one file, "/admin CASACL 20 0" will elevate
# the rights to Owner, but since no second command can be issued on the
# same line, nothing further happens.

# We recommend you put a CASACL command at the top of every configuration
# file your remote administrators are going to include; it serves two
# purposes then: it guards the file from unauthorized inclusion, and
# it makes sure all the commands in the file work whenever the initial
# CASACL command is passed, provided you test it once with any account.
# This avoids scripts that only work partially and leave your server
# in an unhealthy state.

# Oh yeah, CASACL is short for Check And Set ACcess Level.

#########################################################################
#
# Chat Commands
#
#########################################################################

# They have been mentioned in the previous section, so why not document
# them here? The following chat commands are available to authenticated
# users of high enough access level:

# /admin <command>

# executes the console command <command> with the access rights of
# the invoking user.


# /op <player name> <optional access level>

# gives another player a higher access level; the level defaults to the
# level one lower than the caller's access level, which is also the maximal
# possible level.

# /deop <player name>

# reverses /op; it takes away a player's access level, effectively making
# him unauthenticated again. Only works on players of lower access level than
# the invoker, of course.

# /promote <player name> <optional steps>

# elevates a player's access level the given number of steps (default: one).

# /demomote <player name> <optional steps>

# lowers a player's access level the given number of steps (default: one).

# Of course, you can't promote or demote someone of a higher access level than
# yourself, and you can't raise a player's access level to more than one level
# below yours with either command.


# /lock

# Locks your current team. Nobody can join it any more on their own.
# To let someone in, you need to invoke

# /invite <player name>

# From that moment on, the player is allowed to join you. Another effect
# of /inivte, even if your team is not locked, is that the invited player
# can read all of your team's /team messages. Invitations are permanent
# until revoked. That means a player who is invited into your team can
# join and leave it freely without further need to /invite him again.
# Players who were on the team when you /locked it are not automatically
# invited when they leave on their own account.

# /uninvite <player name>

# reverses /invite. The invitation is revoked, the player can no longer
# join you, and if he currently is on your team, he will be thrown out.

# /unlock

# makes your team available for everyone to join again.

#########################################################################
#
# Man in the middle prevention
#
#########################################################################

# when a client authenticates, it sends the IP address and port of the
# server it thinks it is connected to along with the password hash.
# If that IP doesn't match the IP the server thinks it runs under,
# login is denied. Two cases need special attention:

# If your public server is on a LAN and you expect players to connect over
# that LAN in addition to players coming from the Internet, those clients
# will send the LAN IP of the server, which won't match the public IP, so
# the authentication gets rejected. To allow clients from the LAN to bypass
# the check, set this to 1:

TRUST_LAN 0

# If your server does not talk to the master servers, it never gets told
# what its public IP is. You can set it manually with the following command:

#SERVER_DNS <your public ip or a DNS name resolving to it>

#########################################################################
#
# Various
#
#########################################################################

# The log format in ladderlog.txt is picked so that no unauthenticated
# user can ever appear under the same name as an authenticated user. To
# achieve that, @ signs are escaped for unauthenticated users. That
# changes their names relative to the way they appeared in older versions
# of the server. If you rather want to keep the names of unauthenticated
# players as they were before, change this to 1:

LEGACY_LOG_NAMES 0

# Then, instead of mangling unauthenticated names, the authenticated names
# get a 0: prepended before them.

# Really, really stupid users can be banned via their user ID with

# BAN_USER <user>

# Players of average intellect will not be stopped from playing by this,
# but they won't appear in your logs as authenticated and won't collect
# rating points for their account, so maybe this is not so useless as
# it seems. You can revert a ban with

# UNBAN_USER <user>

# and get a list with

# BAN_USER_LIST

# You can reserve a screen name to a certain user:

# RESERVE_SCREEN_NAME <screen name> <user>

# All other players, authenticated or not, will not be able to change their
# screen name to the picked name, then.  Use quotes around the screen name
# if it contains spaces, or replace the spaces with _. @s in the screen name
# need to be escaped ( @ -> \@ ).

# You can bend authenticated user names around with

# USER_ALIAS <user> <alias>

# after doing that, a player who authenticates as <user> will appear
# as <alias>. He will get granted the access rights you gave both
# IDs.

# By default, the authentication names of all players are visible to
# everyone. You can grant your players a certain degree of anonymity
# by allowing all players of a certain maximal access level to hide their
# identity with

ACCESS_LEVEL_HIDE_OF 20

# However, to users of the minimal access level

ACCESS_LEVEL_HIDE_TO 2

# , all user names are shown at all times.