Op 06-05-11 09:02, Hans de Goede schreef:
On 05/05/2011 11:04 AM, Richard Hartmann wrote:
> On Thu, May 5, 2011 at 10:58, Hans de Goede<hdegoede(a)redhat.com> wrote:
>> With Bas' approach every game binary (or rather the sources it is build
>> from) still needs to be patches to use the passed in fd, rather then
>> to open the highscore file itself.
> Correct. This is inevitable unless upstreams adopt either patch.
Plus, both approaches are almost identical when it comes to this patch.
The only difference for the upstream code is what happens at the start.
However, that is a significant difference IMO:
- Your code is 14 lines (excluding comments) of non-trivial (IMO) code.
What you would need for my solution is 2 lines, and it is trivial:
/* At global level. */
/* In main. */
/* The scoreboard file is opened by game-helper as fd #3. */
scoreboard_filehandle = fdopen (3, "r+");
This means that the executable must be started from the helper, unless
it allows an invalid file handle. For this, the helper package could
provide a script to which the games packages can put a link in /usr/bin:
game-helper /usr/share/$game/highscores /usr/share/$game/$game
game-helper must then of course check that everything is right (the
highscore file exists and is group-writable and the executable exists.
>> 2) The rest of the code will be a simple standardizes
>> directly at
>> the start of main, and once control is passed this snippet all
>> rights are permanently gone, see here for the snippet Fedora is
> The other approach would also result in one single snippet (unless I
> am forgetting something)?
Right, so from a security pov and needed patching pov both approaches
are equal, except that having a special right helper also requires:
-adding launcher scripts / modifying .desktop files
-writing such a helper
Actually, with the launcher script above included in game-helper,
.desktop files don't need to be modified, and adding the script comes
down to adding a symlink.
Your approach requires:
- sgid rights on every game with highscores, making it harder to see
which executables require extra auditing attention.
- a significant amount of identical code at the start of each game,
which must all be changed if something is wrong, or something extra is
desired. It really comes down to including a tiny static library in the
source, and has all the problems that come with it.
One such extra feature I'm thinking of right now, is to implement a
standard highscore file format which games can use. Then game-helper can
check if the file is in that format (by reading the header), and if so,
it can check that there is no nonsense in it. That way, it will become
harder to attack a game by writing malicious code into the highscore file.
This just illustrates that my approach is similar to using an external
shared library, with all the benefits that come with it. Of course, when
adding such extra features to game-helper, it should do:
- Open highscore file
- Drop priviledges
- Do extra stuff
- Start game
More importantly, Fedora has already been using the approach I
for a few years, and has patches for many games for this already and
has been feeding these upstream where possible.
That's really good!
So on one hand we have this approach which looks good on paper, and
on the other hand we've this approach which looks equally good on
Not equally good, IMO.
and which is actually implemented already for a lot of
Which means that the bulk of the work for the other approach is already
done as well.
I'm happy to write the game-helper. The rest that would be required is:
- Replace your code snippet with my single line.
- Change the packaging to put the executable in
/usr/lib(/games)?/foo/foo and highscores in
- Let the package make a link to /usr/(bin|games)/game-helper from
/usr/(bin|games)/foo and depend on game-helper.
I agree that this is some work, especially with the packaging. Per game
it's not much, though, and I do think it's worth it.
Which to me makes it really easy to decided which approach
To me, the downsides of your approach are significant. Of course, they
are even more present in the game without any of these patches. So for
two reasons I'm very happy with the work you've done on this so far:
- It makes things better
- Most of the work you did is usable for what is IMO the best approach,
so your work is not lost if we go there.