Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=469585 --- Comment #20 from Mamoru Tasaka <mtasaka@xxxxxxxxxxxxxxxxxxx> 2009-01-04 09:36:30 EDT --- (In reply to comment #19) > Interesting. Which Fedora release and which RPM version? I've _no_ issues to > rebuild or install this package on plain Fedora 10 and CentOS 5. Maybe we can > get out, what's broken here (btw, rpm2cpio <src> | cpio -idm would have also > worked). Both on my rawhide i386 system and koji scratch build fails (ref: http://koji.fedoraproject.org/koji/taskinfo?taskID=1031143 ) > Danger is everywhere. You could exploit vi(1) with nice stuff, insert and > execute your own malicious code written in the file, vi is going to read and > edit - I guess vi case does not apply for the case in this package. What I am saying is that the malicious code inserted by _one_ person is read by _another_ person unintentionally (i.e. like the case in which some malicious png file created by unknown person on the internet is accessed by local users). For /bin/vi case, the impact of the risk should be limited to the person who intentionally tried to read the file. > AFAIK this even was recently possible and is now fixed there. For me > this example is the same situation as what you try to describe above, but for > software like vi this seems much more dangerous to me rather to moon-buggy. So I don't think vi and moon-buggy are the same situation. > There is always some risk once more than a single user is able to touch a > file. Yesterday evening when enabling that feature I already had some kind > of IRC discussion on #fedora-devel. But removing the highscore feature isn't > acceptable for me at all. Then please do this in the safe way. By the way the basic problem I think is that the file "mbscore" is created by arbitrary person. > My C knowledge isn't the best, but when reading read_version2_data() or the > read_version3_data() from highscore.c, the C code seems to be good. On the > other hand, there AFAIK was no CVE report for that possible issue ever, even > many various Linux distributions deliver(ed) moon-buggy to their users. So > why should I feel not good for Fedora here? Because Fedora is more careful? (actually security responsible team on RedHat is very concerned about setuid/setgid binaries: e.g. https://www.redhat.com/archives/fedora-security-list/2007-April/msg00004.html ) > [20:32:08] < rsc> Packagers around? I've got a game which would like to write a > multiuser highscore file. Where? /var/games/%{name}/*? And which permissions? > Program offers setgid with games user. > [20:32:22] < ixs> why not? > [20:32:39] < ixs> but I'd give it a special user... > [20:32:42] < ixs> for security reasons > [20:32:56] < ixs> or simple remove the highscore feature > [20:33:08] < rsc> ixs: wäh! > [20:33:18] < ixs> :> > [20:34:30] < lkundrak> ixs: yes, rsc is right > [20:34:53] < ixs> ahh come on > [20:34:57] < ixs> nobody needs highscores > [20:34:58] < ixs> amirite? > [20:35:54] < lkundrak> ixs: i suggest looking at some already existing game. > probably nethack or something like that > [20:37:11] < ivazquez> Using games should be fine. What are they going to do, > overwrite other games' high scores? :P > [20:37:35] < rsc> lkundrak: existing games are doing what the program offers > (setgit + /var/games/) > [20:37:51] < rsc> lkundrak: at least one, I was pointed to. > [20:38:43] < ivazquez> nethack and Maelstrom both use the games group. > [20:40:14] < rsc> ivazquez: /var/games/%{name}.highscore or > /var/games/%{name}/highscore or what would you suggest? > [20:44:53] < ivazquez> I would put it in its own directory. > [20:45:19] < ivazquez> I would consider /var/games to be a games-specific > /var/lib. > [20:47:43] < rsc> ivazquez: thanks -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review