Installing a server for a game automatically auto-inits and runs every boot.

[Troy James Sobotka]

Binary package hint: tremulous-server

Summary: Installing the means to start a server for an entertainment game automatically puts it into the /etc/rc* startup sequence, thereby potentially opening a large security hole. This happens with little information to the end user, and should be _optional_ or offer a quick and easy way to see what is happening with the rc* startup sequences.

Affects: tremulous-server, wesnoth-server to mention two. I suspect there are more.

[Áron Sisak (asisak)]

I suppose most users installing a game server want it to be started every time they turn on their computers.
Users who don't need it all the time should stop it.

Is there some official specification / policy / ... for this?

[Troy James Sobotka (troy-sobotka)]

I can think of a few notes:

1) No server should automatically start for a game. They are _not_ necessary for standard game playing, and can be launched from within the entertainment software. Often the server software is installed for a more temporary basis than say, something akin to Apache, and therefore should be treated accordingly.
2) Absolutely, under no circumstance, should a game schedule an open port server policy with _zero_ level of feedback notification.

I find this technique to be fundamentally flawed and insecure. We _should_ develop a game policy for server startup / shutdown.

It is also worth mentioning that an average gamer might not be familiar with the rc.* level startup / shutdown sequence format. Perhaps providing the scripts but leaving them _off_ would be wise?

[Áron Sisak (asisak)]

Why does a game server fall into other category as another servers? An FTP server does mean a security flaw, however if I install an FTP server I am (should be) aware of its dangers.
If I install a game server (that is in another package than the game) am I not supposed to know what am I doing? But none of the game servers should be installed by default with the game (since they won't be needed most of the time).

If I remember correctly, there are some packages that install servers but ask if they should be started automatically (I cannot think of another example but the CVS pserver, there might be some another as well).

[Emilio Pozuelo Monfort (pochu)]

Is it ok to close this bug, providing wesnoth-all doesn't depend on wesnoth-server anymore? Or do you still think installing wesnoth-server shouldn't mean the server is automatically run at boot?

[Troy James Sobotka (troy-sobotka)]

As with all things, my view isn't the end all comment.

My gut feeling tells me that installing a game server traditionally (in Windows for example) doesn't imply an automatic "starts every session" boot process. Separating the server from the basic game would make logical sense and probably be a step towards a more secure system.

I am still of the belief that installing a package shouldn't necessarily automatically start the server. We should probably take our cues from one of the more secure operating systems out there -- OpenBSD -- and leave it up to the user to set their 'startup' applications where a package simply installs the tools required. It would be nice to have a security policy on this, but alas, I don't know how often the subject comes up.

[David (launchpad-davidsev)]

I don't think *anything* should ever start at boot without user interaction.
For tremulous, it should have a nice little GUI or something, and start it so it doesn't send to the master server (+set dedicated 1 (1 is lan, 2 net)). If someone wants it to run on-line, then they have to get more up to date stuff etc, so wouldn't want that package.

Also, with the current set up, there are loads of servers with the default name spamming the list.

[ubuntu_demon (ubuntu-demon)]

I can confirm this bug for wesnoth-server. I stopped this auto-starting behaviour. I only start a server when I want to play a game of wesnoth with a friend.

IMHO there needs to be a question like "do you want wesnoth server to be automatically started on boot up?" IMHO all game server packages need a dialog like this. IMHO for regular server packages (apache,openssh-server,...) starting them automatically is fine.

[Johnathon (kirrus)]

I believe that this issue is a packaging one, and that it should be fairly easy to fix. Tagging as such.

[Emilio Pozuelo Monfort (pochu)]

We can't just disable the server. The only thing I see that could work is a debconf question which defaults to enabling it, but let's you tell it not to enable the server.

I would like to see what the Debian maintainers think before making this change.

[Rhonda D'Vine (rhonda)]

It always has been the default policy that when someone installs any server package they also want to have it running - this is expected behavior. The difference between a game server and any other server is just minimal here with respect to the purpose, but still, people expect that server gets started when they get installed.

[David (launchpad-davidsev)]

Game servers don't just eat resources and open a potential security hole, (Your tremded package is years old), but they also cause headache for other people. The tremulous master server has a constant list of un-configured, useless servers in it, causing spam and wasted CPU cycles. It will also be causing a large amount of wasted bandwidth for the server, which in some places can be charged by the byte. (Laptop on a mobile phone link could be very expensive).
Also, when people install this package there intention isn't to run a server for the world, its to play with there friends on a lan. The package you have is not at all suitable for a internet server, there are countless bugs and none of the features required to administer a server. The client package already has the ability to do this, so this package is obsolete, and should be removed. (In my opinion.) At the very least it shouldn't announce its self to the internet by default, and preferably not run at all.
What percentage of people with it installed even know it is running?

[Emilio Pozuelo Monfort (pochu)]

David wrote:
> What percentage of people with it installed even know it is running?

We intentionally created the wesnoth-all metapackage so that people installing
wesnoth did get the campaigns, sounds, etc but didn't get the server installed.
So if someone has wesnoth-server installed it's because they have manually
installed it, as no package in the archive Depends, Recommends or Suggests it.

I'd be bothered if I had a server running and installing the wesnoth-server
package didn't properly configure with the default parameters the server, as
it's expected for a Debian package shipping a daemon.

[Rhonda D'Vine (rhonda)]

David wrote:
> Game servers don't just eat resources and open a potential security
> hole,

 That's not different from any other server.

> (Your tremded package is years old),

 That's not mine, and I won't speak for that because I don't have taken
any proper look at it.

> but they also cause headache for other people. The tremulous master
> server has a constant list of un-configured, useless servers in it,
> causing spam and wasted CPU cycles. It will also be causing a large
> amount of wasted bandwidth for the server, which in some places can be
> charged by the byte. (Laptop on a mobile phone link could be very
> expensive).

 That's a completely different issue then. If the server doesn't have a
sensible default configuration that should definitely be changed.
Claiming that it shouldn't run when one installs it is though a
different topic.

> Also, when people install this package there intention isn't to run a
> server for the world, its to play with there friends on a lan.

 I wonder how you claim to know what the intention of people installing
a server package is?

> The package you have is not at all suitable for a internet server,
> there are countless bugs and none of the features required to
> administer a server.

 Then propably the default configuration of that server should be
inspected more deeply and changed to something sensible.

> The client package already has the ability to do this, so this package
> is obsolete, and should be removed. (In my opinion.)

 As long as someone cares for something and maintains it and is
responsive there isn't any reason to remove something just because some
people don't like it. They just won't have to install it, that's all.

> At the very least it shouldn't announce its self to the internet by
> default, and preferably not run at all.

 That goes again into the direction of some sensible default where I
agree with you (not on what sensible defaults are (because I still don't
know tremulous) but that the daemon should be configured for those).

> What percentage of people with it installed even know it is running?

 I would expect quite a lot. People installing apache are always aware
of that it runs, likewise with ntp, proftp, dancer-ircd, you name it.
I absolutely see no difference with game servers in this area.

 So long,
Rhonda

[Troy James Sobotka (troy-sobotka)]

Honestly, as a relatively non-newb when it comes to package installation, I had _zero_ clue that the various game servers were auto starting.

A game server is _unlike_ an HTTP / SSH / FTP / etc. server, and as such, should probably be subject to different rules as compared with the aforementioned examples.

A game server is, under most situations, something that you would enable when you wish to play the game. Very few people out there wish to run a constantly connected and dedicated game server. That said, you require the servers in some entertainment packages to play them via a network scenario with friends.

At the very least, I would suggest that a popup window should notify an end user that the server is running automatically every boot alongside with possible details on how to disable this feature on a per-startup basis. This could easily prove useful for other servers such as HTTP.

[Siegfried Gevatter (rainct)]

Setting the status to Incomplete as there is no consensus on what the solution is. Please raise this issue for discussion in some mailing list (like <email address hidden>, for example).

[Jonathan Marsden (jmarsden)]

It has been three months. Was this discussed on ubuntu-motu? I can't find anything in the list archives.

I think there are two distinct issues here:

  (1) Should a game server start a boot by default?

  (2) Should a game server add itself to a global Internet "game server locator" by default?

Regarding (1), Troy simply asserts that "a game server is _unlike_" other servers, doing so primarily on the grounds that such game servers are often temporary. However, some people run temporary FTP or HTTP servers, too, so I'm not sure this is truly a difference in their essential nature! There are certainly game servers out there that run 24x7 (WoW, Second Life, many MUDs and MOOs, etc.).

However, some assistance for newcomers who for some reason don't expect servers to actually serve may possibly be desirable for game servers. I'd therefore propose that a well-phrased debconf question (i.e. one asked at server installation time) is sufficient to make it clear to newcomers that once installed, in the Unix/Linux/Ubuntu world, servers really are expected to serve. If you don't want that to happen for this game server, then basically either speak now (answer the debconf question appropriately at server install time) or else learn how to manage services on your machine.

Regarding (2), if the most common way to use a particular game server is in fact LAN-based local usage, then logically the game server configuration should *not* default to announcing itself to a global locator service, much less waste bandwidth constantly talking to such a central locator.

Therefore, for wesnoth-server, I think this default should be changed, *if* in fact it currently announces itself to the Internet (David seems to be talking mainly about a completely different game server, which is a little confusing). A quick test running wesnoth-server while running wireshark to see what it was doing on the network suggests that by default it does *not* go out there and announce itself. In which case, of course, no change is needed in this regard.

Two questions:

A. Does anyone have evidence that wesnoth-server is in fact misbehaving and announcing itself to the global Internet upon startup, by default?

B. Would anyone object to a debdiff adding an install-time debconf question about whether to automatically start the server at boot time?

Jonathan

[Pauli (paniemin)]

I think wesnoth-server shouldn't start wesnothd server automatically at statup. Why so?

Wesnoth client will require wesnothd to be present for some functionality in 1.6 and is already requiring wesnothd in 1.5 development versions. This is only for minor lan game feature.

Solution that I would think of is that wesnothd binary can be installed using package wesnoth-server which doesn't make it auto start.
If someone wants to host MP server that starts always that would be provided by wesnoth-mp-server package. mp-server package would depend on wesnoth-server and only install configurations to run wesnothd at start up.

[Dara Adib (daradib)]

Which of the following binary packages are affected by this bug?

alien-arena-server
armagetronad-dedicated
bzflag-server
conquest-server
crossfire-server
cyphesis-cpp
fceu-server
freeciv-server
ggz-game-servers
ggzd
imazesrv
infon-server
liquidwar-server
monopd
nexuiz-server
openarena-server
pennmush
pioneers
pioneers-console
pokerth-server
pybridge-server
pybridge-server
pyscrabble-server
sauerbraten-server
tama
teeworlds-server
tetrinet-server
tetrinetx
tinymux
warsow-server
xfrisk
xpilot-ng-server
xtux-server

If so, the affected packages might need to be added to the package affected list in the bug report.

Once a consensus is reached, the proposed solution should be written as a blueprint rather than a simple bug report . The blueprint should list all of the known affected packages and what shall be done.

However, I am not sure I agree with making so many changes to Universe/Multiverse packages, unless upstream (Debian) accepts them.

[Troy James Sobotka (troy-sobotka)]

The bureaucracy is unfortunate.

I reported this a year and a half ago. I'd like to think that we in Free Software are capable of making swift decisions when the situation warrants it. While we wait, how many systems are running daemons that a typical user is unaware of? Consider the following negatives:

1) As note above, a game server can pose a potential serious security hole.
2) As noted above, some game servers report to master servers clogging up the network.
3) As noted above, the server will use up vital system resources.

While I largely agree with Jonathan Marsden ( https://bugs.launchpad.net/ubuntu/+source/tremulous/+bug/109434/comments/16 ), I'd also point out that even _typical_ servers would be illogical to immediately run as there is generally no infrastructure in place to make the running of the server _immediately_ useful. Apache might be a good example here as you are presented with an immediately running daemon despite likely having zero content established. Alas, that is potentially another subject.

I find _any_ server that is run by default as soon as a package is installed extraordinarily foolish. OpenBSD has an absolutely astonishing security track record in this regard, and as such, perhaps we should examine Debian's policy on this matter. Let us not forget that it wasn't that long ago nasty worms such as Blaster and its ilk made their way into systems with default open ports.

I would hazard a guess that a typical audience member expects applications to be installed in a usable state when using their package managers. I sincerely doubt that the same audience member expects the application to be immediately run as with the case of a server. Do we expect application xxx to immediately run after selecting the checkmark in Synaptic and pressing "Apply"?

By stalling and endlessly discussing this matter, we are opening up yet one more hole for security blunders as Free Software becomes a larger player, and as a result, a larger target for malicious attacks. _IF_ Ubuntu seeks to bring Linux and Free Software to a more typically mainstream audience, it should consider the implications thereof. Considering the historical (Windows Blaster and like exploits) and similar contextual (OpenBSD's default policy for packages) data, I would hope that the most rational choice is clear.

To ignore the historical and contextual information seems not only foolish but destined to repeat the same mistakes all over again.

[David (launchpad-davidsev)]

You're wasting your time.
To use tremulous as an example, (even though this bug now covers more things), it runs by default, eats a lot of RAM, spams the network, (~2-3k, enough to kill dial-up), has knows security flaws that have been bulk-exploited on at least one confirmed occasion (that I've seen), and people who install it have to instantly replace it all in order to get a working server with the features they have come to expect.
Its obvious Ubuntu doesn't care at all about the security of its users, so I'm just going to give up on this.

[Siegfried Gevatter (rainct)]

Was this raised on the ML?

[Rhonda D'Vine (rhonda)]

* Troy James Sobotka <email address hidden> [2009-01-20 07:24:54 CET]:
> 1) As note above, a game server can pose a potential serious security hole.

 As noted above, every server can pose a potential serious security
hole. A game server is nothing different in that respect from any other
server, and it always was the default to enable something that gets
installed for the people - otherwise they propably wouldn't install it
at first.

> 2) As noted above, some game servers report to master servers clogging up the network.

 I would highly doubt that any game server reporting to a master server
could be considered "clogging up the network", that would be a serious
defact in the network protocol used and should be addressed seperately.

> 3) As noted above, the server will use up vital system resources.

 ... just like any other application that gets installed and/or started.
By the same reasoning evolution should be banned because it uses up
vital system resources (and has quite some memory holes, as a side note
...).

> While I largely agree with Jonathan Marsden (
> https://bugs.launchpad.net/ubuntu/+source/tremulous/+bug/109434/comments/16
> ), I'd also point out that even _typical_ servers would be illogical to
> immediately run as there is generally no infrastructure in place to make
> the running of the server _immediately_ useful. Apache might be a good
> example here as you are presented with an immediately running daemon
> despite likely having zero content established. Alas, that is
> potentially another subject.

 Exactly, and I am opposed to having such an approach addressed only for
some game server packages but rather as a broader infrastructural
benefit for all servers available.

> I find _any_ server that is run by default as soon as a package is
> installed extraordinarily foolish.

 Yes, I'm with you on having this posibility, but then doing it in this
very bugreport is the absolute wrong way to address it.

 When it comes to David's claim of that tremulous having "knows security
flaws that have been bulk-exploited", is there a fix around for that,
where is the reference to that it's known? Calling something known but
not giving any references to it won't help to getting things fixed ...

 I can just repeat myself with respect to wesnoth-server: I am willing
and looking forward to adopt any framework that allows to define wether
a server should be started or not upon installation by default, I though
object to do it within this single package, I don't see the gain for
that approach and needed duplication of work for other packages, at all.

 Sorry.
Rhonda

[Troy James Sobotka (troy-sobotka)]

And while we wait or fail to address this, countless other installations will happen.

Worse still, we have a plethora of installations that are happily waiting the unsuspecting audience member that has installed a game server.

The big problem here is that more than a year and a half has passed and we don't have a resolution in any way, shape, or form. I'd be pretty certain that at least one person that has read this report is capable of raising and forcing the issue to either be resolved or dismissed.

Debian's policy is absolutely absurd on servers. How much vision does it take to realize that this is a fundamental security problem? How much vision does it take to realize that it impacts our audience _right now_? How much vision does it take to realize that this should have _nothing_ to do with politics?

Remember the Debian security debacle from a few months ago? Remember the black eye? How would more feel? Say hello to Ubuntu XP edition...

Passive security is no security.

[Rhonda D'Vine (rhonda)]

* Troy James Sobotka <email address hidden> [2009-01-21 03:54:37 CET]:
> And while we wait or fail to address this, countless other installations
> will happen.

 Installations that want the server and get it in a way ready to use.

> I'd be pretty certain that at least one person that has read this
> report is capable of raising and forcing the issue to either be
> resolved or dismissed.

$> sudo dpkg-divert --local --rename /sbin/start-stop-daemon
$> sudo ln -s /bin/true /sbin/start-stop-daemon

 Of course this is a crude hack, but it will make no servers be started
for you. Technically the symlinking of /bin/true should rather be
replaced by either a wrapper script that gives some warning, maybe even
asks if the server should be started when a tty is available, or do
something else.

> Debian's policy is absolutely absurd on servers. How much vision does
> it take to realize that this is a fundamental security problem?

 I think you are fundamentally overreacting here. When someone wants a
server installed it can be safely assumed that they want to have it
running. Given that the package maintainers are expected to ship
sensible defaults for those servers it rather sounds hypocritical to
call it a fundamental security problem. Where the defaults aren't
sensible this has to be addressed with the package maintainer at hand.
There are e.g. some server packages around that don't start because they
can't sensibly offer sane default values to start out with.

> Remember the Debian security debacle from a few months ago? Remember
> the black eye? How would more feel? Say hello to Ubuntu XP edition...

 Can we please come back to compare things that are at least remotely on
the same level or connected in any way? Thanks.

> Passive security is no security.

 Noone forces people to install server packages. And even then I would
really love to have it addressed in the big picture and *not* have
wesnoth and tremulous singled out. Fighting the same thing for every
single package won't get us anywhere.

 So long. :)
Rhonda

[Bodinux (bodinux)]

As regular linux _user_ for several years now, I don't know how to stop wesnothd from running at startup.

I installed this to play one game with my son, I might play only a few games a year. I don't want this server to be started by default.

I would have thought appropriate to have a way to start it manually or automatically.

As a _user_ my only choice right now is to remove it through synaptic. As a _user_ finally, I can assure you that many did install it once and probably have no idea that it is still running in the background.

[Gabriel M. (gabrielm)]

This bug shouldn't be left to expire. The typical use for wesnothd server is to do a lan game, maybe once a week, nobody leaves it to run all the time except the few well-known servers hosted on wesnoth.org.
I don't know if you realize it, but usability for this is currently much better on Windows, since it doesn't shove a constantly running service down your throat: wesnoth just starts the server as needed and then kills it once every participant has disconnected.

[Rhonda D'Vine (rhonda)]

 Hi!

* Gabriel M. <email address hidden> [2010-03-15 19:01:17 CET]:
> This bug shouldn't be left to expire. The typical use for wesnothd
> server is to do a lan game, maybe once a week, nobody leaves it to run
> all the time except the few well-known servers hosted on wesnoth.org.

 I'm with you - but I don't like an approach to have wesnothd singled
out like that. This is calling for a bigger fix than "just" in wesnoth,
see former comments, installing server packages are expected to have
them running, that's part of the policy.

> I don't know if you realize it, but usability for this is currently
> much better on Windows, since it doesn't shove a constantly running
> service down your throat: wesnoth just starts the server as needed and
> then kills it once every participant has disconnected.

 That though is something I just discussed with upstream, and this is
indeed the case. I am reconsider my standing on that grounds and offer a
switch for this, but it will take a bit to come up with a proper
approach. I fear this is too late for lucid to get included.

 Thanks for the additional ping and proper arguments!
Rhonda

[Rhonda D'Vine (rhonda)]

  The recent update of the wesnoth-1.8-server package does contain a partly fix for this: Unfortunately I didn't set stop symlinks for the runlevels 2 through to 5 so the server will still get started upon installation. Though, it won't get started anymore after a reboot.

 I'm uncertain if a fix for that really warrants yet another update, the fix would be pretty small: Change the line with dh_installinit in debian/rules to have the argument 'stop 20 0 1 2 3 4 5 6 .' instead of the missing 2 3 4 5.

 Sorry for being late, maybe this could go in through some proposed update later on with the above mentioned small fix if it's too late for now.

 Enjoy,
Rhonda

[Launchpad Janitor (janitor)]

This bug was fixed in the package wesnoth-1.8 - 1:1.8.1-1

---------------
wesnoth-1.8 (1:1.8.1-1) unstable; urgency=low

  * New upstream stable release.
  * Obsolete removed patches: missing-wml-child-error, lobby-crash
  * Fix icon names in desktop files (LP: #566115)
  * Add branch version to menu file.
  * Actually add stop links for all runlevels (LP: #109434)
  * Switch debian/watch to stable releases only again.
 -- Ubuntu Archive Auto-Sync <email address hidden> Tue, 18 May 2010 14:28:31 +0100

[Thomas Hotz (thotz-deactivatedaccount)]

Hey guys what to do with the Tremulous bug? Thank you for your help!

[Franck (alci)]

On Ubuntu 16.04, I was hit by the unexpected (by me) behaviour of wesnoth-server, and noticed it just now (after probably 6 month running the server on each boot. My first idea was to go to /etc/default/wesntoh, looking for a ENABLE=1, but there is none.

So I think that:
- the fact that the server will run on each boot should be much more obvious on installation
- there should be simple way to disable it (something like /etc/default/wesnoth)

I support the view that installing a game server is most of the time for playing a network game occasionally, and running a permanent game server is probably a less frequent use case (which might require explicitly enabling the server on boot)

(notice this bug was opened... 8 years ago)

[Franck (alci)]

Also notice that the startup script is not up to date, so systemd fails to disable it:

$ sudo systemctl disable wesnoth-1.12-server.service
Synchronizing state of wesnoth-1.12-server.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install disable wesnoth-1.12-server
update-rc.d: error: wesnoth-1.12-server Default-Start contains no runlevels, aborting.

[Rhonda D'Vine (rhonda)]

     Hi,

* Franck <email address hidden> [2016-08-23 14:27:46 CEST]:
> On Ubuntu 16.04, I was hit by the unexpected (by me) behaviour of
> wesnoth-server, and noticed it just now (after probably 6 month running
> the server on each boot. My first idea was to go to
> /etc/default/wesntoh, looking for a ENABLE=1, but there is none.

 Of course there is none because that's an approach to the issue that
was rather a strange approach in the first place.

 systemctl disable wesnoth-1.12-server # would be the proper way

 But: It doesn't get enabled by default in the package, since the 1.8
times, 6 years ago. See above.

> So I think that:
> - the fact that the server will run on each boot should be much more obvious on installation

 This shouldn't be the case. I'll have to test that in an 16.04
environment, but as far as I can tell this shouldn't happen.

> - there should be simple way to disable it (something like /etc/default/wesnoth)

 "systemctl disable wesnoth-1.12-server" is the simple way and works
with every single service. No strange file that might or might not be
supported or used.

> I support the view that installing a game server is most of the time for
> playing a network game occasionally, and running a permanent game server
> is probably a less frequent use case (which might require explicitly
> enabling the server on boot)

 That's why it was changed six years ago. :)

> (notice this bug was opened... 8 years ago)

 (notice this "bug" was resolved in wesnoth... 6 years ago)

 Enjoy,
Rhonda
--
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los |