It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
immi101: If an attacker can place some malicious code under your user account, your account is already compromised anyway. Having write access to a game won't make that any worse.
avatar
eiii: No, placing the code on your system alone is only the first step. An attacker also must manage you to execute that code. If all the programs you execute are installed as system programs which you cannot overwrite as a normal user he has no chance. His code will never be executed. But when an attacker finds a file which you usually execute and which he can overwrite then he has won. And that's where your game binary comes handy, which you have installed as a normal user and which he can overwrite. So the attackers code will be executed when you start your game the next time.
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.

avatar
immi101: Kerbal Space Programm
avatar
eiii: Oh, I had that on my wish list. :(
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. ;)
avatar
immi101: 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.
.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.

avatar
immi101: 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.
That's privilege escalation and a different topic, even more easy as there are usually more known local exploits than remote ones.

avatar
immi101: 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. ;)
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, ...
avatar
Klumpen0815: Since the .sh can be extracted instead of installed as well, I don't really see any downsides yet, but maybe I missed something, apart from the fact, that you have to create a directory yourself if you choose to extract rather than install.
avatar
eiii: The difference between the old .tar.gz files and the new .sh format is less technical, but more in the responsibility. The .tar.gz files were officially provided by GOG, so extracting the game from the .tar.gz file and running it that way was officially supported, which it isn't anymore now.

The difference between the .deb files and the new .sh format is that with the .deb file GOG was forced to set the permissions correctly as the game has been installed under a different user (root) as it has been run later. They now can be more careless with the permissions as they require the game to be installed with the same user which later runs it. That makes the life harder for people which want to install the games read-only under an own user and generally doesn't increase the security of the game installations.
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.
avatar
hedwards: It works, it's just that there's things that GOG would have to do to make make it work. Probably something like unionfs mounted over the top of the installation directory would be the easiest fix. It would mean that you absolutely could not use the same game by different people at the same time, but it would work.

There's also solutions to the problem involving hard links and profile specific copies that would probably also work.
avatar
immi101: as I said, of course you can make it work somehow by jumping through several hoops. It is just a considerable amount of additional work. Considering that there hardly is any use-case where you really need a working multiuser setup, i don't think it is worth the effort. I rather get my linux installer quicker and without any complicated setup.
For me the best case scenario would be where every game is just a self-contained, portable folder, that I just need to unzip and be ready.

side note: using a non-upstream kernel feature like unionfs isn't really a working solution for the installer, i think. There is overlayfs in new-ish kernels which supposedly can do the same. But I haven't tried that yet.
@ssokolow
though you might want to check that out. It might do what you want for your sandboxing
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.
Post edited August 17, 2015 by ssokolow
avatar
Ciris: It's a year of Linux gaming on GOG.com!

Today, we want to share with you a few new updates to the way that installing our games on Linux will work. Based on what we've learned and on your feedback, we have revamped our installers to offer a much improved experience, and make it more consistent with the way we do things on Windows and OS X.

Starting today, our Linux games will come with all-new installers that include more features, combine the best of our previous solutions, and plain ol' look better. Among other things, here's what you can expect:

--The new installers will be distro-agnostic. That means that you'll be able to run and try them out on virtually any Linux distribution without any tweaks.
--A simple installation process, done in just two steps that we all know well: simply add executable privileges to the installer, then simply run it.
--Patches. Differential patches. No one likes downloading lots of data for an update, now you'll be able to grab future patches for big games with frequent updates.
--Support for installing DLC.
--Pretty backgrounds, pretty desktop icons.

For more info about the new installers, you can always check out our Linux FAQ.
1. I've noticed that "The Last Federation" has an .sh installer for the main game but still .deb and .tar.gz for the expansion.
2. Why did you take down the other language versions (German, French, Spanish, etc...) before the new files are ready? They are completely unavailable now.
Will there be an announcement when the other languages are ready?
Post edited August 20, 2015 by Klumpen0815
avatar
Ciris: It's a year of Linux gaming on GOG.com!

Today, we want to share with you a few new updates to the way that installing our games on Linux will work. Based on what we've learned and on your feedback, we have revamped our installers to offer a much improved experience, and make it more consistent with the way we do things on Windows and OS X.

Starting today, our Linux games will come with all-new installers that include more features, combine the best of our previous solutions, and plain ol' look better. Among other things, here's what you can expect:

--The new installers will be distro-agnostic. That means that you'll be able to run and try them out on virtually any Linux distribution without any tweaks.
--A simple installation process, done in just two steps that we all know well: simply add executable privileges to the installer, then simply run it.
--Patches. Differential patches. No one likes downloading lots of data for an update, now you'll be able to grab future patches for big games with frequent updates.
--Support for installing DLC.
--Pretty backgrounds, pretty desktop icons.

For more info about the new installers, you can always check out our Linux FAQ.
avatar
Klumpen0815: 1. I've noticed that "The Last Federation" has an .sh installer for the main game but still .deb and .tar.gz for the expansion.
2. Why did you take down the other language versions (German, French, Spanish, etc...) before the new files are ready? They are completely unavailable now.
2. Will there be an announcement when the other languages are ready?
1. Fixed.
2. We're bringing those back ASAP. Call of Cthulhu: Prisoner of Ice already has its separate Linux installers available.
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?
Post edited August 20, 2015 by sbolokanov
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.
avatar
Ciris: Starting today, our Linux games will come with all-new installers that include more features, combine the best of our previous solutions, and plain ol' look better. Among other things, here's what you can expect:
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).

avatar
sbolokanov: By the way what compression does the sh use. Zip or gzip?
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).
Post edited August 20, 2015 by WinterSnowfall
avatar
sbolokanov: By the way what compression does the sh use. Zip or gzip?
avatar
WinterSnowfall: 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.
avatar
WinterSnowfall: 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).
avatar
sbolokanov: 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.)
Post edited August 20, 2015 by ssokolow
avatar
sbolokanov: Cool, thanks.
avatar
ssokolow: 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!
avatar
ssokolow: (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.)
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?
avatar
ssokolow: (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.)
avatar
shmerl: 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.
Post edited August 21, 2015 by ssokolow
avatar
ssokolow: 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/
Post edited August 21, 2015 by shmerl