Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
nethack doesnt expect users to be able to set their own high scores or manipulate state files, on most UNIX-like systems this is true, but for some reason not on gentoo, where users are added to group games, rather than having group games reserved as a special group to prevent tampering with high scores and so on. from readentry() in topten.c: ... static const char fmt33[] = "%s %s %s %s %[^,],%[^\n]%*c"; ... else if (fscanf(rfile, fmt33, tt->plrole, tt->plrace, tt->plgend, tt->plalign, tt->name, tt->death) != 6) tt->points = 0; ... unchecked fscanf() from the group games writable record file in /var/games/nethack. I could create a record entry that will overflow a heap buffer and execute arbitrary code with the rights of any users who play nethack. Also note that there are most likely many more of these bugs, and as I can create save games as any user, that are automatically read when those users play nethack. reproduce: perl -e 'print "3.4.3 0 0 0 0 0 0 0 0 0 0 FOO BAR FOO BAR FOO,","A"x"50000","\n"' > /var/games/nethack/record then when you die (or use nethack -s), nethack reads the file. Note this is not a bug in nethack, it's due to gentoo's group games policy.
games team: please advise how you want to proceed.
Regrouping issues, same cause for two bugs : ========================= As gentoo doesnt follow the standard of setting games to setgid a low privileged group, any user in group games can create symlinks in /var/games/nethack/save, allowing them to trick other users to overwriting or creating files. reproduce: cd /var/games/nethack/save ln -s /any/file/victim/owns <uid><username>.bz2 now get victim to run nethack, when they save their game target file will be overwritten or created. This only affects gentoo, and is not a bug in nethack. ====================================
*** Bug 122376 has been marked as a duplicate of this bug. ***
games team give permission to mask until a fix is available
masked pending resolution of this issue, do we want a maskglsa?
This is a B2 issue, so unless games is planning to fix this fast we need a masking glsa.
The problem with us taking any quick action on this is fairly simple. The Gentoo games team has a policy where we restrict who can run games based on the games group. This is similar to how performing raw reads on cdrom devices is limited to the cdrom group, or how running vmware-workstation is limited to the vmware group. This has been in place for a long time and is well-received by our users. To revert this behavior is not something that we wish to do, nor something that can be accomplished overnight as *all* games ebuilds rely on this behavior. Our thinking has always been that the system's administrator puts only trusted people in the games group and that he understands that they will be able to run these games. While I do see the points brought up in these recent bugs, they seem to completely ignore that the way the Gentoo games team does this is what is wanted by our users. Now, we don't have a better solution just yet, but we are working on it. Feel free to mask the games that are showing problems such as these until we can come up with a proper solution that is acceptable to us without removing current functionality, nor being vulnerable to these issues.
Restricting who can access specific hardware and potentially dangerous applications is quite different from restricting who can access games. Nobody would expect granting permission to play games would allow them to compromise other users accounts or disrupt other users legitimate use of the games, but this is exactly what can happen. what functionality is it that you dont want to remove, the ability to limit who can execute games? I've already suggested how this can be achieved in an email to vapier without breaking high scores, security, etc. I never received any reply though, if you'd like me to bounce you a copy just ping me on irc.
please send email like that to games@gentoo.org
Is this an issue for games-roguelike/slashem as well? If so it should also be masked.
Thanks Raymond, you are correct, slashem is also affected, filed as bug 127167
I agree with jaervosz, we need a mask glsa if there is no change coming soon, which is probably not the case according to comment #7
Yup, we'll need a masking GLSA if there's no fix soon. Games team, could you please comment when you expect to have this fixed?
As I stated before, for this to be "fixed" requires a complete rethinking of how we do games on Gentoo, requiring us to make modifications to our eclasses which affect ~750 packages, along with determining how to come up with a clean upgrade path for our users which already have games installed and established on their systems. Needless to say, there's no expectation on this happening any time soon. If you want my opinion on it, I would say we simply mask the packages and let the users decide on their own if the risk is worth it, but I know that this is definitely not the optimal solution, but until we have another workable solution that is agreeable to our members, this will be our current course of action.
What is the reason for having the ability for only certain users to able to run games (ie. the existence of a games group). It would seem that one could start creating groups for all sorts of applications. Is there are group called "office"? Is there a group called "graphics"? Why I need to be in a group called games to play games is a mystery to me. If a sysadmin wanted to restrict the use of "office" applications to certain users, he would have to do some extra work, no? Why not make them do the same thing for games? Chris said: "This has been in place for a long time and is well-received by our users." Why is it well-received? What is so great about it? Tavis said: "what functionality is it that you dont want to remove, the ability to limit who can execute games? I've already suggested how this can be achieved in an email to vapier without breaking high scores, security, etc. I never received any reply though, if you'd like me to bounce you a copy just ping me on irc." Tavis: Why not post this email here?
(In reply to comment #15) > What is the reason for having the ability for only certain users to able to run > games (ie. the existence of a games group). It would seem that one could start > creating groups for all sorts of applications. Is there are group called > "office"? Is there a group called "graphics"? Why I need to be in a group > called games to play games is a mystery to me. If a sysadmin wanted to restrict > the use of "office" applications to certain users, he would have to do some > extra work, no? Why not make them do the same thing for games? Except that I don't care about "office" stuff, since I'm on the games team. Quite frankly, I'm a bit put off by the fact that our policies are under attack like this. Nobody has made any complaints about this policy until this bug came about, and even those people seem to be complaining just to complain. Want a reason why we restrict games to a specific group? How about limiting who can run games that are extremely resource intensive? How about keeping your kids from playing doom3? Need any more reasons? Well, I'm sure you can think of some on your own. The point here is that no matter how much anyone wants our policy to be under fire here, we don't have any intentions on changing it because a few packages behave poorly. > Chris said: "This has been in place for a long time and is well-received by our > users." > > Why is it well-received? What is so great about it? Wow. I just don't even know what to say. Maybe there are people that have a differing opinion than yourself? What's so great about allowing anyone on the system to run as many copies of ut2004-ded out of the box just because you happen to want to run *one* on your server? My point is that any argument you make can have another side to it. Why bother? Also, we are getting *way* off the topic of security here and moving into policy, which is not the point of this bug, at all. Were I to take nethack and patch it to no longer have these vulnerabilities, I would be 100% satisfying the requirements of this bug, so policy changes are not necessarily dictated. We also could remove the insecure package. Again, policy changes are not dictated by this move. > Tavis said: "what functionality is it that you dont want to remove, the ability > to limit who can execute games? I've already suggested how this can be achieved > in an email to vapier without breaking high scores, security, etc. I never > received any reply though, if you'd like me to bounce you a copy just ping me > on irc." > > Tavis: Why not post this email here? Here's the quick and skinny... Add a new group to limit who can play games. Quite simply, it is unworkable, as it would require a revision bump to *every* games package in the tree to ensure they all get the new permissions. I've already stated this, but it seems to be ignored. Now, a *workable* solution would be to create a *new* group and have the games setgid to *that* group, but it would still require locating the games that are affected, and ensuring that the game runs with that gid, while still restricting usage to members of the games group. Again, we have not come to a consensus on what to do abotu this, so continued prodding isn't helping the situation and quite frankly is frustrating us to no end. Please let us come up with a solution on our own time. The game is now masked.
just FYI: two other packages have been masked cause of dependencies... [from package.mask cvs log:] revision 1.5122 date: 2006-03-22 23:30:14 +0100; author: wolf31o2; state: Exp; lines: +2 -1; commitid: 5a584421cff54567; Added games-roguelike/noegnud-nethack due to nethack masking. ---------------------------- revision 1.5121 date: 2006-03-22 23:23:07 +0100; author: wolf31o2; state: Exp; lines: +2 -1; commitid: 63a14421ce4b4567; Masking games-util/hearse since it depends on nethack, which was masked by secur ity.
1) The way to fix this IMO is to make nethack and all it's clones/interfaces setgid to a group called nethack of which nothing else in in particular no users are members (for security), while making the datafiles (leveldescriptions etc) owned by games, without read-permission for others. That way NetHack will fail to start for people who aren't in games, without compromising security. 2) Falconseye is also an interface for nethack (it comes with it's own internal copy of NetHack 3.4.1), but it isn't masked. (Rather offtopic...) Actually I wouln't mind terribly if it were marked for removal: It's been unmaintained for years and there is a successor called vultureseye (of which I am a developer :-). Vultureseye will be releasing 2.0 within the next week or 2 after which I'll be submitting an ebuild for it...
And another: noegnud-slashem is a nethack variant too and no doubt has the same problem...
falconseye is bug 127319
Masking GLSA 200603-23 sent. Moving to enhancement scope pending resolution.
(In reply to comment #16) >Quite frankly, I'm a bit put off by the fact that our policies are under >attack like this. Nobody has made any complaints about this policy until this >bug came about, and even those people seem to be complaining just to complain. No one had reason to complain until the policy broke things. I always felt it was a bit odd, but as long as it didn't inconvenience me I saw no reason to complain. Now it is, so I do. >How about limiting who can run games that are extremely resource intensive? If your problem is resource usage, limiting what resources users have is a better solution. >How about keeping your kids from playing doom3? You could just as well want to stop them watching some movies. And you would implement that yourself, you wouldn't expect the system to do it for you. >The point here is that no matter how much anyone wants our policy to be under >fire here, we don't have any intentions on changing it because a few packages >behave poorly. Then you fix the packages. It's an unusual policy, not done by any other distro afaik, with no noticeable benefits for the vast majority of users, and it's breaking some pretty important (as games go) packages. > Wow. I just don't even know what to say. Maybe there are people that have a > differing opinion than yourself? What's so great about allowing anyone on the > system to run as many copies of ut2004-ded out of the box just because you > happen to want to run *one* on your server? Nothing. But there's nothing particularly wrong with it either - we do it with lots of programs all the time. What's great is being able to play nethack. For me, and I think for the majority of users, the benefits of your policy are not worth making it impossible to (securely) play nethack. > Also, we are getting *way* off the topic of security here and moving into > policy, which is not the point of this bug, at all. Were I to take nethack and > patch it to no longer have these vulnerabilities, I would be 100% satisfying > the requirements of this bug, so policy changes are not necessarily dictated. I suspect if you do that it will be an issue that keeps cropping up. It's not a bug with nethack, it's a bug with your policy. Anyway, changing the policy is an obvious solution - if you think patching it is easier, then by all means go ahead. > We also could remove the insecure package. Again, policy changes are not > dictated by this move. I feel that from a user's point of view, changing the policy would be preferable to removing the package. I repeat, it's not the package that's responsible for the insecurity, it's the policy. > > Here's the quick and skinny... Add a new group to limit who can play games. > > Quite simply, it is unworkable, as it would require a revision bump to *every* > games package in the tree to ensure they all get the new permissions. I don't see how, all it would mean is that users would have to remain in the games group (with the security issues this causes, but we would be no worse off than we are now) until all games had been updated. How was the policy first implemented? Because it seems to me changing the group would be no different. > Please let us come up with a solution on our own > time. The game is now masked. > As a user, that's not an acceptable situation. Why not remove the policy of having games not runnable by those not in the games group until you can figure out a way to reimplement it without causing security issues?
"It's not a bug with nethack...." It absolutely *is* a bug in nethack. Nethack shouldn't write to symlinks and shouldn't blindly read the record file.
(In reply to comment #23) > It absolutely *is* a bug in nethack. Nethack shouldn't write to /sys and > shouldn't blindly read the record file. > How is blindly reading the records file any different from blindly reading its own executable or the libraries it's linked against? In both cases you're just relying on the permissions to ensure it hasn't been maliciously modified.
(In reply to comment #8) >I've already suggested how this can be achieved in an email > to vapier without breaking high scores, security, etc. I never received any > reply though, if you'd like me to bounce you a copy just ping me on irc. > please post your suggestion to this bug, so people can decide if they want to implement this or follow gentoo policy.
I wonder if this policy is maintained, shouldn't we test all games to make sure that all games that overwrite or create files via a symlink are security masked?
(In reply to comment #22) > (In reply to comment #16) > >Quite frankly, I'm a bit put off by the fact that our policies are under >attack like this. Nobody has made any complaints about this policy until this >bug came about, and even those people seem to be complaining just to complain. > > No one had reason to complain until the policy broke things. I always felt it > was a bit odd, but as long as it didn't inconvenience me I saw no reason to > complain. Now it is, so I do. I have to admit that I've always wondered how many people actually prefer the current system. Do we have anything other than anecdotal evidence? > As a user, that's not an acceptable situation. Why not remove the policy of > having games not runnable by those not in the games group until you can figure > out a way to reimplement it without causing security issues? Chris actually did answer this question. Such a change would involve changing every single game in portage, and that's a _lot_ of games (and thus a _lot_ of work). As such, the games team would like to consider alternative solutions before trying to implement sweeping changes.
(In reply to comment #22) > (In reply to comment #16) > >Quite frankly, I'm a bit put off by the fact that our policies are under >attack like this. Nobody has made any complaints about this policy until this >bug came about, and even those people seem to be complaining just to complain. Until a bug came about - people may have been hesitant to complain. > No one had reason to complain until the policy broke things. I always felt it > was a bit odd, but as long as it didn't inconvenience me I saw no reason to > complain. Now it is, so I do. There has been some discussion about this on the forums. The reason games aparently have not heard of it is that we who were discussing realize what a large amount of work is required to fix this - and so have not filed bugs until real bugs were aparent. The gentoo policy causes another related problem: For games that share state or highscore among many player in the fashion of nethack, it is common to share that state over a lan. This breaks in an environment with mixed distros (eg a school). The nethack-group solution will not fix this - because I can still forge the same attack against any other linux/unix flavour (or any other distro) on the same lan. Gentoo's policy also causes problems for people who have nis/ldap enabled on a lan with more than one distro. Ergo, don't mix gentoo with other distros. To say that this policy is well recieved should mean that it has seen praise IMHO. Has it? Here's some earlier discussion: http://forums.gentoo.org/viewtopic-t-346526.html In short, doesn't gentoo break expected behaviour here?
FWIw, I've wondered about the grouping, too. And in the end, if you're trying to restrict access to games, using a games group is the wrong way to do it - there's nothing to stop a user from compiling their own version in their home directory, especially since the toolchain doesn't use a group of its own.
I've always disliked Gentoo's system requiring users to be in games as well, but haven't felt it was a big enough thorn to actively complain. A user can compile a game on their own (there's no 'gcc' group to restrict toolchain use, of course), so it seems like a needless waste of the sysadmin's attention. If we need to limit what our users are doing we can do it via resource limits, quotas, etc.
Guys, please keep in mind that this is a security bug in the first place, not really a discussion board. Also, please have some faith in gentoo: of course the games and security team are currently discussing possible solutions to address this issues. Unfortunately, the said discussion is not very transparent to the community at the moment to make things easier for us, but I expect that this will change after things are well discussed internally. Any further attacking of the gentoo games policy really makes no sense right now, it only sets up the games team. Keep in mind that they introduced the policy with good intentions, so please dont flame them right away if things aren't working like expected. > To say that this policy is well recieved should mean that it has seen praise > IMHO. Has it? Heh, praise is pretty rare. I'd say that usually no complaints are enough to indicate that things are "well received".
After all the flames, I'd like to say I really like the idea that users have to be in a games group before they can play games. This way I can easily allow and disallow certain users to use my computer for games. Unfortunately, it has not been very good implemented: 1. All users in the games group can fiddle with the scores 2. Users not in the games group can still run e.g. gnometris but they have to do some research why their highscores are never saved (yes, I've been there) So I think it would be great if 1. the security bug could be fixed, 2. the scores-issue could be fixed, 3. the mixed distro problem could be fixed and 4. if still possible, the games group would stay.
This bug has a thread in the forums. It's at: http://forums.gentoo.org/viewtopic-t-446415.html It might be best to use the forum for further discussion.
(In reply to comment #16) > Here's the quick and skinny... Add a new group to limit who can play games. > > Quite simply, it is unworkable, as it would require a revision bump to *every* > games package in the tree to ensure they all get the new permissions. I've > already stated this, but it seems to be ignored. Now, a *workable* solution > would be to create a *new* group and have the games setgid to *that* group, but > it would still require locating the games that are affected, and ensuring that > the game runs with that gid, while still restricting usage to members of the > games group. I think a two-group system might be the most workable, where there is one group users must be in to play games, and another group that the games run sgid as to modify saves and score files and such. As per filip's comment (#28), it would be best if we used the games group the same way other linux/unix distros do so as not to break inter-distro compatability. So perhaps we could have the games group be used in the normal way, and create a second group (gamers?) for users to be able to run the games. Now I understand that this would not be the easiest policy to impliment, but it might be worth doing as a long term solution. Furthermore, it might not be as hard as version-bumping every package in the tree. Why not write a helper script that people can run to make the changes? Similar to the way the python team has python-updater for sweeping changes that break things, perhaps there could be a games-update script that would change the permissions on things in /usr/games/bin and take users out of the games group and put them in the gamers group. The games eclass could perhaps then be modified print an enotice to run this script if it hasn't already been run. (I realize it would not be quite that simple, but perhaps it could be a starting point. -Nate
*** Bug 129954 has been marked as a duplicate of this bug. ***
(In reply to comment #34) > As per filip's comment (#28), it would be best if we used the games group the > same way other linux/unix distros do so as not to break inter-distro > compatability. So perhaps we could have the games group be used in the normal > way, and create a second group (gamers?) for users to be able to run the > games. That would have also minimize the changes, as all files installed and accessed by games would stay in the games group. Of course, as the filesystem just changes IDs and does not really store names, the name does not matter that much, but still it makes things somewhat easier. And it has the added benefit that in the worst case, after the change (to the group file) no user will have access to games that were not already updated, as the game is accessible only to games and not to gamers. So the admin would have to install the new revision or run some updater to make the games available again, but until then the system is on the safe side and the admin will learn rather soon that some action is required. The game has to run as one group (requiring gid of file and sgid bit) while access needs to be restricted to another group (at least if we keep that policy). Maybe this can be done by restricting access on the directory instead of the executable? /usr/games is already restricted to the games group (at least on my system), so that should be enough for any game placing its binaries in this tree, as long as you change games to gamers. Perhaps the same technique could be used for other games as well. Almost all games will reside in /usr/games, or in a directory by themselves that can be restricted as well. Only problem are games that have their binaries in the same dir as non-gaming binaries, like games bundled with some desktop environment or the likes (e.g. kdegames). Those would need some work, probably be placed in a games subdir by themselves and for consistency symlinks placed in the main bin dir. Maybe the eclass could provide some check ensuring access restriction. (In reply to comment #16) > Nobody has made any complaints about this policy until this > bug came about, Like comment #22 said, it was not annoying enough to complain, till this bug. Given the choice, I'd drop this group restriction and leave the sysadmin to worry about caging his/her users. > How about keeping your kids from playing doom3? What is going to prevent them from installing things locally, in their home dir, owned by themselves? As long as you have access to the net and even a compiler available, there are easy ways to circumvent the current games permissions.
(In reply to comment #27) > Chris actually did answer this question. Such a change would involve changing > every single game in portage, and that's a _lot_ of games (and thus a _lot_ of > work). As such, the games team would like to consider alternative solutions > before trying to implement sweeping changes. Maybe a lot of work, but must be done, if this is the best solution. Now with the new "Modular X", gentoo devs needed to update many, many ebuilds. I would say at least half of portage had some update regarding of Modular X. With OpenAL splitted to OpenAL and Alut, then many other ebuilds were also updated. Please, don't avoid doing a big change (if it would be the best change) just because it would need a lot of ebuilds to be changed. If this was the case, then we would not have modular X. If Gentoo Games staff is small, then ask help when such big change is needed. I'm sure people can help.
(In reply to comment #36) > What is going to prevent them from installing > things locally, in their home dir, owned by > themselves? noexec?
From how "lively" the discussion has gone so far in this bug, I'm probably risking my neck right now, but here it goes: After half a year of status quo being a hardmasked ebuild, is there any progress on the solution of making nethack and nethack-based games work safely? I'm no coder, but the two groups idea sounds the most logical to me as well.
two groups isn't good enough. we need to fix the games.eclass to create a new user for every game that we want to support in this regard and run the game binaries setuid for that user. The games team has talked about how to fix it but no coding yet. That's not totally accurate, since we *had* code and spanky lost it. ;-)
Thanks for the explanation. It's good to know a bug isn't just forgotten. Hmm, I thought it would be enough to make a new global group (e.g. games-su) instead of making a new group or user for just about every game. I'm pretty sure someone sugested it already. ...but then again, I'm no coder. I better shut my yap before a new flame war comes up and leave you guys to what you do well enough.
What kind of work is being done to fix this, and has any discussion covered the policy and a possible change in the future? I know it was said that some code had been done and lost (out of curiousity, how?), but I'm just curious.
I write a mail to devteam at nethack.org and they replied me the following: We've modified the development code so that future versions of nethack won't be vulnerable to string buffer overflows while reading in the scores file. As far as using the default setup of ``setgid games'' and also making untrusted users be members of the games group, I don't think there's anything we can do about that. NetHack's "playground" directory shouldn't be writable by users, or by programs other than nethack if those programs let users modify arbitrary files. If `games' doesn't meet that requirement, some other group only used by nethack could/should be created and used. ___
so, mm, what are we doing with this bug? Games team, please comment, is it possible to provide a version that would not be vulnerable? thanks
it's on our list.
(In reply to comment #45) > it's on our list. > Must be some pretty long list... it's been over a year and a half. This is getting ridiculous.
Feel free to submit a patch to get it done sooner.
Created an attachment (id=139487) [details] Add bounds checking to fscanf() format strings Well, that took all of half an hour...
Created an attachment (id=139490) [details] Ebuild patch to protect state directory from modification by users And here's a patch to the ebuild to take care of the permissions issue. (Far be it from me to terminate discussion on Gentoo's games policy, though.)
Created an attachment (id=139499) [details] Revised, policy-agnostic version of ebuild patch ...So, to that end, here's a cleaned-up and revised version of the ebuild patch, which can install the game either using the current Gentoo games policy (of putting users into the games group) or the policy followed by other distributions (of treating the games group as privileged). It turns out there are only a couple of changes needed: creating a separate "nethack" group under the Gentoo policy, and selecting the proper group name for file installation. This version of the patch also runs chgrp/chmod on the data and state directories during postinst to fix permissions from any previous install. That part can be dropped if you tell people to unmerge old versions first. (Or is there a way to tell emerge to copy permissions from ${D} to ${ROOT}?)
Thanks Andrew. Games herd, okay to make a revbump including the patches? please advise.
Andrew submitted patches for this almost three months ago. Are there other problems preventing this from being unmasked? The bug has been out there for two years (and one day) now. Additionally, how is this only classified as an "Enhancement" bug? If this is a big enough problem to have the game masked for two years, shouldn't that be "Major," according to the description "major loss of function?"
(In reply to comment #52) > Andrew submitted patches for this almost three months ago. Are there other > problems preventing this from being unmasked? The bug has been out there for > two years (and one day) now. > > Additionally, how is this only classified as an "Enhancement" bug? If this is a > big enough problem to have the game masked for two years, shouldn't that be > "Major," according to the description "major loss of function?" > It's not only a question of the bug itself, it's that we didn't have a proper fix. Since a GLSA was released and the game was masked, but we couldn't just close the bug because it is not fixed. Therefore, it was left open but severity was decreased to "enhancement", which pretty much means "no stable package is vulnerable, so this is not a priority anymore, maybe it could be fixed when someone cares enough to write a patch". Now, someone actually wrote a patch. Games herd, are you ok to include it? please advise.
Being masked isn't a "major loss of function" but rather an intentional change made to specify the current state of the ebuild. Also, I *really* dislike the idea of putting out an ebuild that violates the policy we've put in place, and can pretty much guarantee that this wouldn't be accepted, as is. Rather, a more generalized solution should likely be used and put in the games.eclass, instead of in individual ebuilds. Otherwise, this whole thing comes crashing down as soon as someone installs any other game from the tree. Also, not running prepgamesdirs isn't really acceptable. Either change prepgamesdirs or do the chmods after, don't drop it.
Created an attachment (id=146573) [details] Revised ebuild patch that runs prepgamesdirs I don't currently have time to dig into games.eclass due to work obligations, but here's a revised version of the patch that runs prepgamesdirs as requested (overriding file ownership/permissions afterwards). For when I do have time, what sort of generalized solution would you be looking for? Setting policy issues aside for the moment, perhaps a variable that indicates whether a game needs its own group? Something like # For games that need their own groups GAME_PRIVATE_GROUP="nethack" pkg_setup() { games_pkg_setup # runs enewgroup ${GAME_PRIVATE_GROUP} } src_install() { prepgamesdirs # does chgrp ${GAME_PRIVATE_GROUP} on relevant directories } # For games that don't need a private group GAME_PRIVATE_GROUP="" pkg_setup() { games_pkg_setup # does nothing special } src_install() { prepgamesdirs # does chgrp ${GAMES_GROUP} on relevant directories }
I just submitted Andrew's scanf format checking fix to the patches area of Nethack's sourceforge page: <http://sourceforge.net/tracker/index.php?func=detail&aid=1949698&group_id=196&atid=300196>
Not one to moan, but this has been state of play for over two years now, little things like this are waht gives the bad reputation. So rather than moaning, whats needs to be done to get this out onto the tree properly
Looking for some clarification as to the currently considered "correct" fix for this. As it stands now, the sgid proposal (make a private group for games such as nethack which control shared files) clashes with the normal use of the games group (well, normal for Gentoo at least) since only one group can be assigned to the executable. Bones mentioned creating a privileged USER instead of group... which makes sense, but only if nethack doesn't make decisions based on the effective-user (e.g. saved games need to be tied to the "actual" user instead of the suid user, somehow). If we can get an official say at this point about the right fix, there may be some people in the woodwork annoyed enough about not getting their shot of roguelike to do the actual coding (Andrew's code will probably help, but he's already said he doesn't have the cycles to rewrite games.eclass).
(In reply to comment #58) > As it stands now, the sgid proposal (make a private group for games such > as nethack which control shared files) clashes with the normal use of the > games group (well, normal for Gentoo at least) since only one group can be > assigned to the executable. As an alternativ to switching from sgid to suid, as you proposed and as would probably involve lots of changes, there is still my suggestion from comment #36 to have different groups assigned to directory and binary, so that the binary can be sgid games in the nethack sense, while a suitable parent directory like /usr/games can be access restricted to games in the Gentoo sense. Of course one of these groups needs a different name.
