So, me and my girlfriends share my linux desktop, and we all play videogames through steam. I have a fairly good solution for sharing the steam game files between users which as you may know is a slight pain on linux especially with games requiring proton. So, the current workaround we have to do is for each user to take ownership of the shared directory after they log in. I’ve been putting off finding a more elegant solution so i just set up a quick alias for everyone to do it for the time being. The command is this:
sudo chown -R user1:steam /share/steam/
The games live in /share/steam, and i created a steam group which we all belong to. However it’s my impression there is no “true” shared ownership of linux directories, they seem to want to always be associated with a primary user which doesn’t play nice with steam and proton. It seems to be a shortcoming with proton more than anything, i did read an article which explains how to create your own fork of proton which fixes this issue, but i want the freedom of being able to hop around proton versions rather than that limitation.
I would like to move to a more elegant solution where this permissions change happens automatically in the background, on login of a given user. I’m sure that it’s possible, but i haven’t been able to find a perfect solution by looking around. It seems like making a systemd module might be best? I’m probably gonna give that a go, but i wanted to see if anyone had a better idea or any feedback at all.
Thanks!
Pretty much anything “low-level” you do in linux should be done through systemd. Running sudo is usually a disaster. I wouldn’t know much beyond that. I have the Flatpak version of Steam installed which I think would work much better for this since when you add a directory to flatpak Steam it does some fancy stuff to map it into the program’s mount namespace for reading and writing. So if you want to add an external drive or directory to Steam you just “Add Drive” and it will make it accessible.
So, the most obvious thing is to run the command gksudo, which ought to prompt for the password on login. Your user enters their password and it all works.
Don’t do that.
Number one it’s bad practice to blindly enter your password and number two having a user editable script that you run blindly every time you log in is a real vulnerability.
If you can do it with groups, do that. Have everyone be in the group and have the permissions of the directory let them do what they need to do if they’re in the group.
If that doesn’t work for some reason (you can change steams file creation mask) then acls are the next thing to try.
First thought, can you put the command in a script and then set the setuid bit to run it as root?
Another thought, and this might be preferable but would require more work and research, look into automount and how USB storage devices are automounted. On many distros they are auto mounted on something like /media/user with all the perms and ownership of the current logged in user. I know you are not talking about USB but it should be a similar type of automount. You could create an exported nfs share on your /share/games dir, and then (auto)mount it with appropriate perms and owners in your user directory /home/user/whatever.
Also look at some other mount options like “bind” and loopback.
After spending a few minutes reading about how steam handles .acf files and how unpredictable that is, the most elegant solution would be more storage.
Is it not sufficient to just
chmod -R g+rwxs /share/steam
? That should get you read/write/execute and also set thesetgid
bit so that any files created there will be assigned the proper group (I expect this is probably the issue that otherwise demands changing ownership of files between logins).i think with proton games it’s not enough. https://github.com/ValveSoftware/Proton/issues/4820 from my knowledge, proton seems to demand that prefixes are “hard” owed by current user, shared isn’t good enough
I am a dumb dumb, but can you set specific commands to be run as sudo without password in the sudoers file?
Or the setuid bit?
this is looking like the most convenient option, thanks
you might be able to do this with overlayfs