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. The 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 a 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 `:nethack`.

[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