New comment by ashpooljh on void-packages repository

https://github.com/void-linux/void-packages/pull/27036#issuecomment-743483318

Comment:
As of `nethack-3.6.6_1`, the `nethack` binary is installed with the SGID bit (not SUID as I have written in the comment, sorry) and is owned by `nethack:nethack`. This is needed on multi-user systems so that the playground files (e.g. `/var/games/nethack/record`) are writable no matter what user runs the game.

To access these files, the game needs to chdir into the playground. A default path to the playground can be supplied using the `HACKDIR` macro at compile time, and the value can be overridden at runtime using a command line flag or an environment variable. This is where the `SECURE` macro comes in: if the path supplied during runtime is different from the default one (`HACKDIR`) and the `SECURE` macro is defined, the game sets `uid` and `gid` to those of the actual user running the binary. Without this, any user would be able to write into any directory as `:nethack`, which is somewhat of a security oopsie.

Except for the two occasions where this happens on the `unix` target ([1], [2]), I couldn't find any functional checks involving `SECURE`.

I was originally planning to make compile-time `HACKDIR` consistent with the install-time `HACKDIR` and keep `SECURE` undefined, because defining it would break the game: it would drop privs upon chdir into the non-`HACKDIR` playground, be unable to open `record` and exit. However, now I recognize the clever hack behind making `HACKDIR` different during compile-time: this allows to set a different directory as the _default_ playground, even if it's not where the binary is installed. I have therefore opted to leave this hack in place and define `SECURE` to mitigate the slight security risk of rogue-like `:nethack` (pun intended).

[1]: https://github.com/NetHack/NetHack/blob/5c291bc54022f74a17985b6a54ac2174bba18700/sys/unix/unixmain.c#L477
[2]: https://github.com/NetHack/NetHack/blob/ac9ba384497879dd935bdf2aa86714dc2a35edd1/util/recover.c#L102