that sounds like a very theoretical threat. If I have write access to the user account there are a hundred places that I can use to get the user to execute my code.
.bashrc, .xsession, crontab, autostart-entries from kde/gnome/etc, and probably a few more if you think about it a bit.
and those are a lot more reliable than depending on the user having game xyz installed and launching it.

Your scenario is only a real danger if the attacker has access to user account X and can overwrite file F which is usually executed by user Y. In this case he can extend his privileges to that of the user Y.
But here we have only user X and file F which is only executed by user X.

question is do you really want to miss a game because it has some "badly programmed" parts? You are gonna miss a lot of good ones.
I mean I would still read a good book even if it comes with a shitty cover and a bad binding. ;)

.bashrc, .xsession and crontab are only sourced or interpreted and not executed directly, which makes it at least a bit harder (I don't know about Gnome or KDE mechanisms as I don't use them). But you are right, with a few shell tools you could get access through these files too. I wouldn't have thought it's that easy. You only need to craft an URL which makes your browser download a file and overwrite one of these files.

That's privilege escalation and a different topic, even more easy as there are usually more known local exploits than remote ones.

Not because of a single anti-feature. But I add it as another point to my negative list like incomplete version, regional pricing, no Linux support, no German language support, ...

There's no real problem with that. The executables are being executed with the privileges of the user that invokes it. So, the game only has access to things that you have access to. If it's really that much of an issue for you, you could create a GOG group and assign the game to that group and then only grant it permission to those directories.

But, really, this is just how those things are done. There haven't been any particular problems with doing it like this and there are tools available if it doesn't work right, but in practice there's not much reason to do so.

My main issue with overlayfs is that it was merged in 3.18 and *buntu 14.04 is still on 3.13 but it turns out that Canonical has been including it in their Ubuntu kernel patchset since 11.10. :)

When I realized that, I did a little poking around and came up with this command: :)

sudo mount -t overlayfs -o lowerdir=/mnt/buffalo_ext/games_inst,upperdir=~/.local/share/games/ overlayfs /mnt/buffalo_ext/games_play

References:
http://askubuntu.com/a/109441/23552
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/overlayfs.txt

Now I just need to look up a nice, low-effort way to sandbox MojoSetup installers so they don't gunk up my homedir if I decide I've encountered something I can't fix myself and need to contact GOG support.

Well nice to see deb changed to .sh.
It's a good call. By the way what compression does the sh use. Zip or gzip?

I miss the tarballs though.
Can you please consider bringing them back?

I won't lie: I liked having .tar.gz archives for Linux games.

But I can see the advantages of using a graphic installer, especially for those which are rather new to Linux.

There's still the option of unzipping the script and moving the game folders around wherever you like (not necessarily in your home folder)... and it's not that much of a pain.

Now I just have to redownload every Linux installer our there.

At least I've got good bandwidth, but not everyone does, you do know that GOG, don't you? The incremental patches better be worth it.

Ehm, I still see a tar.gz for Broken Sword 5 - the Serpent's Curse. Did someone forget about it?

Edit: Shadowrun: Dragonfall - a Shadowrun Returns DLC is also still tar.gz. As are the original Linux versions of Broken Sword 1 and 2 (the non-remastered ones).

https://icculus.org/mojosetup/

MojoSetup uses zlib, so gzip. Size differences between old tar.gz archives and the new installers seem to confirm this (usually, scripts only have a couple of extra mbs which hold the installer files).

Cool, thanks.

Actually, MojoSetup uses Zip. GOG's makeself configuration uses gzip.

(A MojoSetup installer is a makeself stub which unpacks a tgz containing MojoSetup which then asks some questions and unpacks a zip file containing the game content.)

They're concatenated one after the other (shell stub, then tgz, then zip file) and you can split out both the tgz and the zip file by running my makeself_safeextract script without the --mojo option. (--mojo makes it ignore the tgz and unpack the zip file for you)

zlib is an implementation of DEFLATE, which gzip, Zip, PNG, and MNG all use. (That's why AdvanceCOMP can use 7zip's optimized DEFLATE compressor to improve all four formats.)

Wait, so GOG's makeself installers use gzip instead of Zip? Interesting!

So is there some easy way for them to use better compression instead of zip there, such as proposed above lrzip? Or Mojo setup isn't flexible enough for that?

I'm not sure. I'm not especially familiar with MojoSetup's capabilities.

On the one hand, the only integration point I could find for the zip code is an array named archives in fileio.c which already lists LZMA-compressed tarballs as an option but, on the other hand, the docs only mention Zip as a supported option for single-file builds. (Possibly because, from what I remember, the other supported options are either weird special formats like UZ2 or formats like .tgz which, in my tests, didn't react well to attempts to extract them without first manually trimming off the SFX stub... which is non-trivial for makeself.)

GOG may not even be compiling MojoSetup themselves (MojoSetup supports operating in a mode where everything game-specific is in the same zip file so you can build your installers with `cat mojosetup.sh game.zip > game.sh`), which would complicate things.

However, that aside, supporting other archive formats still shouldn't be difficult. Worst case, they patch their MojoSetup to do something like reading the archive's start offset from the last 64-bits of the file and then they adjust their build script accordingly.

MojoSetup's approach is actually quite elegant. Archives are optional and the GUI code just sees everything as a directory tree containing Lua control scripts and extra files they may or may not register to be installed or manipulated via various high-level functions the C code exposes to the Lua runtime.

I'd say GOG would benefit from lrzip support in Mojosetup. I can take a look at the code and check how hard it would be to add that, but it's something that GOG probably should implement.

I just noticed that Mojosetup page lists GOG now too :) https://icculus.org/mojosetup/