Just voted. :-)

In the mean time:

gog script to tar.gz converter

example: Shadowrun Dragonfall: gog_shadowrun_dragonfall_director_s_cut_2.6.0.10.sh
usage: ./gogzcnv.sh gog_shadowrun_dragonfall_director_s_cut_2.6.0.10.sh

https://pastee.org/6rjzj

WYSIWYG:

- creates an gog_shadowrun_dragonfall_director_s_cut_2.6.0.10.tar.gz tarball
- root dir is "shadowrun_dragonfall_director_s_cut"
- pure shell script... BUT "unzip" must be installed (if you haven't already done so)
- if you want multi-core compression, install "pigz" - enables itself by default if available
- output is quite similar to the abandoned tar.gz files

i think there are just a lot of games where a system-wide installation for multiple users does not work.
Especially all those old DOS games who just dump their savegames and settings into the installation folder. But even some of the newer linux games work like this.
I never really looked into the DOS games packaged for linux from GOG, but I don't see how you want to make those work with per-user settings & savegames. Unless you go as far as ssokolow and look into filesystem overlays/redirection or do a lot of symlinking. Which imo is just not worth the time and effort.
And a game installed into the system where the (normal) user doesn't have write access, just gets annoying once you start to look into modding ;)
i personally think treating games as personal data and throwing them into $HOME works just fine.

And since all the licenses we get here are personal, single-user licenses anyway i don't really see the necessity of a guarantueed working multi-user setup.

just my 0,02€

Since most of my native games are OK with being installed read-only, I just manually unpack them, change them to "root:root 644 or 755" ownership and permissions, and see if anything breaks.

I didn't want to throw too much effort at a solution which will eventually be replaced by an overlay filesystem to properly support finicky games and DOSBox games.

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.

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

It's not about multi-user installation, but about privilege separation. And so far this has to work for all games were a .deb package has been provided. You just have to set the permissions on selected files or directories correctly in the package. This was not perfect, but a lot better than the new method which probably sets anything to be writable by the user which also executes the game. This widely opens the door for all kinds of malicious attacks.

With the new installer the information which files need to be writable probably gets lost and GOG leaves us alone to find that out when they do not support installation with one user and use as another user.

DOS did not know any better (and therefore got it's pile of worms and viruses). But newer Linux games, that's a shame. Any examples for that?

Agreed. It's OK for me when old games can only be used sensibly by one user. What bothers me is when the user which runs the game also can overwrite it's installation.

You just have to do the modding with the same user you have used to install the game. Modding is a kind of installation process, not normal game usage.

There's another reason why I don't like that, backups. Game installations can be quit big, so they either blow up your backup unnecessarily or you have to exclude the directories manually from the backup, which is tedious and error prone. That's also the reason why I want saved games to be separated from the game installation as there's no need to back up your game installation, but of course I want to back up my saved games.

I don't know if the license is bound to the user which has installed the game or to the PC where the game is installed. But that doesn't matter for me as my goal is not multi-user usage but privilege separation.

That surprises me seeing as that's what they use with those Live CDs, it seems odd to me that it wouldn't be in the kernel.

Anyways, Linux is a multiuser and multitasking OS, it seems crazy to me that the games here haven't been set up to handle that.

hmm, i don't really see any dangerous attack vector. at least not on a standard desktop pc that is basically used by a single user. What exactly can happen when the user can overwrite the game files? The game executable doesn't do anything critically, so I don't see how it could lead to an privilege escalation. All you can do is execute some code with the rights of the user. But then, you already could do that at the point when you modified the game, right?

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.
Unless I am missing something here?

Kerbal Space Programm

I absolutely agree that this is a nice feature. I just don't think that we can expect that gog will develop such a solution for games where this doesn't work out-of-the-box. In the end they are just the distributor, not the game developer. Demanding a guarantee that things like that will always work in their installer seems unfair to me.

live cds usually have a custom kernel. But when making an installer that you want to work in as many environments as possible it's just not a good idea to rely on a feature that is not a standard kernel component.

well, as I said above. That is mostly up to the developer, isn't it? Not GOG. Depending on how the game exactly handles this, support may be easily added .. or it might just be so much work that it isn't really worth the time.

(ps.: i don't think there are any games that can't handle the multitasking :p)

As someone who actually thinks, that the .sh files are a rather good idea (compared to the .deb anyway), is there any reason for me to keep the tar.gz files?
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.

If you're fine with them, then why not? Personaly, I don't want to run any scripts - there's no point for me. I install them inside my home directory and don't want any system wide installations. Speaking of just extracting them (those hybrid scripts) there are several downsides for me: a) unzip has to be installed - tar/gzip is basically always available, b) extracting them generates a warning (because of that script in front of the zip archive) and thus an exit code of 1 - not successful - bad for scripting, c) archives are bigger, d) unzip doesn't support multi-threading -> unpacking takes longer (and gzip is generally faster anyway).

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.

Oh, I had that on my wish list. :(

Thanks, this clears some things up.
They should just eliminate the debs and keep the tarballs then in addition to .sh .

I wrote something based on symbolic links and local copies of specific files for DOS/Windows games, that works well so far.
Of course it would be a mess to do it for each game you install, so I automated the process too.

Here is an example for Divine Divinity if you feel curious:
[url=https://debian-facile.org/utilisateurs:vv222:games:divine-divinity]https://debian-facile.org/utilisateurs:vv222:games:divine-divinity[/url]

PS: My method works on multi-users systems too.

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.