On Sat, Sep 16, 2023 at 05:26:26AM +0300, S V wrote:
> Maybe I understand you wrong, but I didn't return any setgid to code,
> just adding permissions to /var/games/phantasia/* files, or does it
> count as "setgid"?
I believe he means the SGID bit (S_ISGID in <sys/stat.h>) on the
/usr/games/phantasia executable[1], or possibly on the /var/games/phantasia
directory[2]. What seems to be left unstated is that your patch,
+ chmod ugo+rw ${DESTDIR}/var/games/phantasia/*
making the files writable by all is unacceptable; so unacceptable that he's
not even acknowledging it, skipping ahead several steps and responding to a
hypothetical future question.
I would think the proper solution here is to simply add your user(s) to the
games group. But given the warning in the man page, I assume there's more
going on here. Perhaps phantasia isn't ensuring that files it creates have
the correct permission bits or group ownership.
[1] This has the same effect as calling setgid, and people use setgid to
refer to both cases.[3] Not many people use "SGID".
[2] The SGID bit on a directory causes files created in that directory to
inherit the directory's GID, rather than the effective GID of the calling
process. In effect it's similar to a process calling setgid (setegid) before
creating the file.[3] SGID on directories is a BSD-specific feature that I
really like, but perhaps there's a caveat I'm missing. The one practical
caveat I'm aware of is that inheriting the GID isn't useful if the new file
isn't group writable, and the default umask of 0022 masks the S_IWGRP bit.
When using SGID on a shared Git repository, for example, you need to
explictly configure Git to ensure files and directories are group writable.
[3] But a supplementary GID doesn't grant the ability to setgid or setegid
on that GID; in practice it's only root who can change a process' effective
GID, which is why the SGID bit exists.
