Hi Shriram,

On Sat, Mar 16, 2024 at 08:03:02PM +0530, Shriram Ravindranathan wrote:

Package: monopd
Version: 0.10.2-6+b2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: s20n@ters.dev

Dear Maintainer,

monopd.service fails to start (could not bind port 1234), rendering the package unusable.

Mar 16 19:25:02 think182 sudo[4410]: shriram : TTY=pts/0 ; PWD=/home/shriram ; USER=root ; COMMAND=/usr/bin/apt install monopd
Mar 16 19:25:02 think182 sudo[4410]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
Mar 16 19:25:03 think182 systemd[1]: Reloading.
Mar 16 19:25:04 think182 systemd[1]: Reloading.
Mar 16 19:25:04 think182 systemd[1]: Starting monopd.service - game server for board games like GtkAtlantic...
Mar 16 19:25:04 think182 systemd[1]: Listening on monopd.socket - monopd listening socket.
Mar 16 19:25:04 think182 monopd[4512]: monopd 0.10.2 started
Mar 16 19:25:04 think182 monopd[4512]: loaded game configuration: game=[Atlantic]
Mar 16 19:25:04 think182 monopd[4512]: loaded game configuration: game=[Monopoly]
Mar 16 19:25:04 think182 systemd[1]: monopd.service: Failed to parse ERRNO= field value '-2' in notification message: Numerical result out of range
Mar 16 19:25:04 think182 monopd[4512]: could not bind port 1234, exiting
Mar 16 19:25:04 think182 systemd[1]: monopd.service: Main process exited, code=exited, status=254/n/a
Mar 16 19:25:04 think182 systemd[1]: monopd.service: Failed with result 'exit-code'.
Mar 16 19:25:04 think182 systemd[1]: Failed to start monopd.service - game server for board games like GtkAtlantic.
Mar 16 19:25:05 think182 sudo[4410]: pam_unix(sudo:session): session closed for user root

That might be related to the latest change "Add a service template for compatibility reasons with monopd.socket.".

Masking socket activation and enabling the service worked for me:

# systemctl stop monopd@*.service
# systemctl stop system-monopd.slice
# systemctl stop monopd.socket
# systemctl mask monopd.socket
# systemctl enable monopd.service
# systemctl start monopd.service

Kind regards,
Sylvain

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAmX/PRoACgkQDFub3qtEsS+cUACfdaQZ6CyS1JsjJmVswuIdufRz GL0AniA8803+ZhAyMm0+eOzpl3zJ7Bls
=bmnl
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sat, Mar 23, 2024 at 09:35:38PM +0100, Sylvain Rochet wrote:

That might be related to the latest change "Add a service template for compatibility reasons with monopd.socket.".

Actually, the main problem is /lib/systemd/system/monopd.socket which
set Accept=yes while monopd needs Accept=no (which is the default value).

By the way, I just released monopd 0.10.3 that detect this
misconfiguration and exit instead of spinning forever over accept() :)

Sylvain

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAmYAPgUACgkQDFub3qtEsS89zwCgzpcQn5MRE+j9PTSi8iNmpAts kvQAn3rN7cFMc3OVaiAu7ahJujAY8uYJ
=Q9yI
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sylvain Rochet wrote:

Actually, the main problem is /lib/systemd/system/monopd.socket which
set Accept=yes while monopd needs Accept=no (which is the default value).

I wonder if monopd needs a systemd socket file at all and if we should disable the service after the installation. We have been using this setting since the introduction of systemd. If monopd runs with Accept=no then we also don't need a service template file. At some point I also noticed the same warning as Shriram

"monopd.socket is a disabled or a static unit not running, not starting it."  and then followed [1] and added the required template file.

I have been running monopd for the past decade and I also suspect the daemon is affected by some bugs which might be remotely exploitable. Since users usually don't need the monopd server anyway, if they want to play a game, they should make a conscious decision to start it if they want to use it locally. For a simple internet game, the daemon is not required.

[1] https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmYA1TtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQACgkQ2a0UuVE7 UeS8Bg//UkJ2FKhshpHgZRj1vSieVM7Ym6PFsr4gkqYFCL6GnmlpANWP9xv6yLvo EB8eBDNzYhb5RAKKLPjkKbziLQ6UqPXLXi84PSK7V53ELWSyJgwc5kqIPFcC45Dj 1GAaYHMI0wUg1p7yglEnund2dTAgZDTdCnZM8tia6cEMulpZiRrrVg5kRZgJoi9h JGWlx2wp9+iC26y4ncaZIZeAY/M7DvWzb2VFGTkA8MLDJp4r1+y1eHrDs5SOicEP WsN0YRV/1iYQ8dK3gAZBDPxY9cXyYY4ao7VyOSVzCRkEVnox32AxUJr13UI0VNQW 7WR6tBEmt21xL6TnW9A2bDeGGs7IYjeJVHdSg0bL49RyrJFnCsbeyx+1032XucV5 TAPalsHAb/aQavse0uxNNlnu0X8QfKBvSNTsDLI4Wo0hOpsdJaXYaYF6uL0vmzmE +G2UDNrCPWLp/QN95cDzW3e+oqK8IovN7c7+0Yf46WabVWDzUOxUpEb+iuhtg/uP HflQiaKBkuoYJamAPO9s5uulDXXDN/VaNP94oyFfRQrxxpRtIpFaxpA+GInUPAA2 KWVljxtbxcrbYBl6dhih55r3SZMejl2sliWY7F7wTzRO11ITzgKfEtHP2OB0qB0r dnWmaawygMytrrBLqZGChv5//PIALctY4UnnsnfDijtGnFjPXzI=
=+q+/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Markus,

On Mon, Mar 25, 2024 at 02:36:59AM +0100, Markus Koschany wrote:

Sylvain Rochet wrote:

Actually, the main problem is /lib/systemd/system/monopd.socket which
set Accept=yes while monopd needs Accept=no (which is the default value).

I wonder if monopd needs a systemd socket file at all and if we should disable the service after the installation. We have been using this
setting since the introduction of systemd. If monopd runs with
Accept=no then we also don't need a service template file. At some
point I also noticed the same warning as Shriram

"monopd.socket is a disabled or a static unit not running, not
starting it."  and then followed [1] and added the required template
file.

Yeah, socket activation is not really useful for public servers
services, it is mostly used for local services that can be spawned on
the fly later. Furthermore, socket activation breaks monopd metaserver registration because the daemon must be running to register, so better
only ship the service file. I let you decide whether the service should
be disabled or enabled by default (but unless something recently
changed, daemon usually runs by default on Debian. I admit having lost
track :D).

I have been running monopd for the past decade and I also suspect the
daemon is affected by some bugs which might be remotely exploitable.

What makes you think that?

My daemon is running attached to gdb so I can easily catch and trace any
issue that would kill the process. So far it's been over 10 years
without a single issue, some process lived for several years between
systems reboot.

I am not saying it is bug free because nothing is bug free, but if it is remotely exploitable and actively exploited, I would be aware of it on
my running instance.

Since users usually don't need the monopd server anyway, if they want
to play a game, they should make a conscious decision to start it if
they want to use it locally. For a simple internet game, the daemon is
not required.

Installing the server package isn't already a conscious decision?


Kind regards,
Sylvain

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAmYBuNEACgkQDFub3qtEsS+x8gCgoKwGL0qwInLarMJs5yFTg5Yp iTEAn3wDSOSLeqLBU0HaTxGq+KI2EfE7
=I+el
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)